Service Management

Overview of Linux Components

Cheat sheet

Systemd Service Commands

Systemd Information Commands

Systemd commands that show useful system information.\

Changing System State

systemd reboot, shutdown, default target etc

Systemctl Viewing Log Messages

systemctl

Running systemctl without any arguments invokes the default list-units subcom- mand, which shows all loaded and active services, sockets, targets, mounts, and devices.

systemctl

Unit statuses

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.

Targets

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:

sudo systemctl isolate multi-user.target

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:

 systemctl get-default

Set Default Target

 sudo systemctl set-default multi-user.target

see all the system’s available targets

systemctl list-units --type=target 

Dependencies among units

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 dependency to a service

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

sudo systemctl add-wants multi-user.target my.local.service

Execution order

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.

Local services and customizations

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

sudo systemctl enable custom.service

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.

Managing Services

show only loaded and active services

systemctl list-units --type=service

 systemctl -t service --state=active 
 systemctl list-unit-files --state=enabled

all the installed unit files, regardless of whether or not they’re active:

systemctl list-unit-files --type=service

enable/disable boot launch

systemctl enable/disable smb

check status of service

(there is alot of nice information here, including latest logs) systemctl status smb

systemctl status smb

no pager

systemctl -a --no-pager

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)

systemctl -a | grep .

show all service files which are installed

systemctl list-unit-files

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:

systemctl --system daemon-reload

Viewing systemd Information

// Some cosystemctl list-dependencies : Show a unit’s dependencies
systemctl list-sockets : List sockets and what activates
systemctl list-jobs : View active systemd jobs
systemctl list-unit-files : See unit files and their states
systemctl list-units : Show if units are loaded/active
systemctl get – default : List default target (like run level)

manage temp files (/tmp)

 systemd-tmpfiles

Create a systemd Service

common unit file paths

/usr/lib/systemd/system
/lib/systemd/system
/etc/systemd/system
/run/systemd/systemcreating a unit file

creating a unit file

cd /etc/systemd/system

Create a file named your-service.service and include the following:

[Unit]
Description=<description about this service>

[Service]
User=<user e.g. root>
WorkingDirectory=<directory_of_script e.g. /root>
ExecStart=<script which needs to be executed>
Restart=always

[Install]
WantedBy=multi-user.target

For Python specific projects which include virtual environment:

[Unit]
Description=<project description>

[Service]
User=<user e.g. root>
WorkingDirectory=<path to your project directory containing your python script>
ExecStart=/home/user/.virtualenv/bin/python main.py
Restart=always
# replace /home/user/.virtualenv/bin/python with your virtualenv and main.py with your script

[Install]
WantedBy=multi-user.target

OR

[Unit]
Description=<project description>

[Service]
User=<user e.g. root>
WorkingDirectory=<path to your project directory>
ExecStart=/bin/bash -c 'cd /home/ubuntu/project/ && source venv/bin/activate && python test.py'

[Install]
WantedBy=multi-user.target

activate and start the new service

Reload the service files to include the new service.

sudo systemctl daemon-reload

Start your service

sudo systemctl start your-service.service

To check the status of your service

sudo systemctl status example.service

To enable your service on every reboot

sudo systemctl enable example.service

To disable your service on every reboot

sudo systemctl disable example.service

Journalctl

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)

# view logs (each line is short)
journalctl

# view logs with normal line lengths (lines are not contracted), get used to always running -a (For all), a for "showing All of the line".
journalctl -a

# to remove pager (note the pager is removed when command is piped to another one)
journalctl -a --no-pager

# or less words (also no pager & skips blank lines - "grep ." shows only lines with text, so empty lines are discarded)
journalctl -a | grep .

# following the log (synonymous with "tail -f /var/log/syslog"), f for "Following"
journalctl -fa

# follow the log, but also show the 1000 lines before now. n for "Number of lines"
journalctl -fan1000

# show the 100 latest lines of logs
journalctl -an100

# viewing a specific service (kind of like grepping, you can achieve same result with grep). assuming atop is the process we want to monitor
journalctl -a  _SYSTEMD_UNIT=atop.service

# can achieve similar results with
journalctl -a | grep atop

Writing systemd service files

Home | Official Red Hat OpenShift Documentation