Service Management
Last updated
Last updated
disable unused services and ports, remove them from startup tasks.
systemctl stop service-name
systemd stop running service
systemctl start service-name
systemctl start service
systemctl restart service-name
systemd restart running service
systemctl reload service-name
reloads all config files for service
systemctl status service-name
systemctl show if service is running
systemctl enable service-name
systemctl start service at boot
systemctrl disable service-name
systemctl - disable service at boot
systemctl show service-name
show systemctl service info
systemctl -H target command service-name
run systemctl commands remotely
Systemd commands that show useful system information.\
systemctl list-dependencies
show and units dependencies
systemctl list-sockets
systemd list sockets and activities
systemctl list-jobs
view active systemd jobs
systemctl list-unit-files
systemctl list unit files and their states
systemctl list-units
systemctl list default target (like run level)
systemd reboot, shutdown, default target etc
systemctl reboot
systemctl reboot the system
systemctl poweroff
systemctl shutdown (power off the system)
systemctl emergency
Put in emergency mode
systemctl default
systemctl default mode
Systemctl Viewing Log Messages
journalctl
show all collected log messages
journalctl -u sshd.service
see sshd service messages
journelctl -f
follow messages as they appear
journelctl -k
show kernel messages only
Running systemctl without any arguments invokes the default list-units subcom- mand, which shows all loaded and active services, sockets, targets, mounts, and devices.
The last four lines are recent log entries. By default, the log entries are condensed so that each entry takes only one line. This compression often makes entries un- readable, so we included the -l option to request full entries. It makes no difference in this case, but it’s a useful habit to acquire
Many units have no installation procedure, so they can’t truly be said to be enabled or disabled; they’re just available. Such units’ status is listed as static . They only become active if activated by hand (systemctl start) or named as a dependency of other active units.
Unit files that are linked were created with systemctl link. This command creates a symbolic link from one of systemd’s system directories to a unit file that lives else- where in the filesystem. Such unit files can be addressed by commands or named as dependencies, but they are not full citizens of the ecosystem and have some no- table quirks. For example, running systemctl disable on a linked unit file deletes the link and all references to it
The masked status means “administratively blocked.” systemd knows about the unit, but has been forbidden from activating it or acting on any of its configuration direc- tives by systemctl mask. As a rule of thumb, turn off units whose status is enabled or linked with systemctl disable and reserve systemctl mask for static units.
systemd does define a distinct class of units (of type .target) to act as well-known markers for common operating modes. However, targets have no real superpowers beyond the dependency management that’s available to any other unit.
The only targets to really be aware of are multi-user.target and graphical.target for day-to-day use, and rescue.target for accessing single-user mode. To change the system’s current operating mode, use the systemctl isolate command:
The isolate subcommand is so-named because it activates the stated target and its dependencies but deactivates all other units.
To see the target the system boots into by default:
Individual units can turn off these assumptions with the line:
DefaultDependencies=false
in the [Unit] section of their unit file; the default is true . See the man page for systemd.unit-type to see the exact assumptions that apply to each type of unit (e.g., man systemd.service).
all the options in the table express the basic idea that the unit being configured depends on some set of other units. The exact dis- tinctions among these options are subtle and primarily of interest to service devel- opers. The least restrictive variant, Wants , is preferred when possible.
You can extend a unit’s Wants or Requires cohorts by creating a unit-file.wants or unit-file.requires directory in /etc/systemd/system and adding symlinks there to other unit files. Better yet, just let systemctl do it for you.
add my.local.service as a dependency to multi-user.target so when ever the system is in multi-user mode this service will be started
When the system transitions to a new state, systemd first traces the various sources of dependency information outlined in the previous section to identify the units that will be affected. It then uses Before and After clauses from the unit files to sort the work list appropriately. To the extent that units have no Before or After constraints, they are free to be adjusted in parallel.
Browse the examples in /usr/lib/systemd/system and adapt one that’s close to what you want. See the man page for systemd.service for a complete list of configuration options for services. For options common to all types of units, see the page for systemd.unit. Put your new unit file in /etc/systemd/system. You can then run
to activate the dependencies listed in the service file’s [Install] section
As a general rule, you should never edit a unit file you didn’t write. Instead, create a configuration directory in /etc/systemd/system/unit-file.d and add one or more configuration files there called xxx.conf. The xxx part doesn’t matter; just make sure the file has a .conf suffix and is in the right location. override.conf is the standard name..conf files have the same format as unit files, and in fact systemd smooshes them all together with the original unit file. However, override files have priority over the original unit file should both sources try to set the value of a particular option.many systemd options are allowed to appear more than once in a unit file. In these cases, the multiple values form a list and are all active simultaneously. If you assign a value in your override.conf file, that val- ue joins the list but does not replace the existing entries. This may or may not be what you want. To remove the existing entries from a list, just assign the option an empty value before adding your own.
all the installed unit files, regardless of whether or not they’re active:
(there is alot of nice information here, including latest logs) systemctl status smb
same way to achieve no pager (pipe to another command, and it will auto remove the pager - "grep ." discards empty lines, showing only lines with text, useful for screen realestate)
if you edit a /lib/systemd/system file (a unit file/ a service file), then you need to reload it into systemd using this, after that you can do things like "restart","start","stop",etc to that service:
Create a file named your-service.service and include the following:
For Python specific projects which include virtual environment:
OR
Reload the service files to include the new service.
Start your service
To check the status of your service
To enable your service on every reboot
To disable your service on every reboot
Looking at logs (All system logs are saved into the journal now, also saved on /var/log/, but in a journal folder which has binary data)
