Service Management
Last updated
Last updated
disable unused services and ports, remove them from startup tasks.
| Command | Description |
|---|---|
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.\
| Command | Description |
|---|---|
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
| Command | Description |
|---|---|
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
| Command | Description |
|---|---|
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
NOTE: services are stored in /lib/systemd/system
services that are started on boot, are symlinked from here, to the above folder: /etc/systemd/system/multi-user.target.wants
multi-user.target.wants, represents the default run level
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)
