Gini and Karl's world |
story time |
science club |
math blog |
computer corner |
penguin page |
Linux: systemd in a nutshell
I have been very skeptic about systemd and why one would need to replace
the existing init scripts. It was easy to add or change things in those
init scripts and they did the job. However when you change from a system with
init scripts to one based on systemd you notice immediately a big difference: startup time. Systemd boots a lot faster. My Thinkpad boots in under 10s with
systemd. Even an optimized init script based system will need more than 20s on
the same machine.
OK, now I have systemd but how do I use it? You can find a lot of general documentation about using systemd at https://www.freedesktop.org/wiki/Software/systemd/ and Arch linux has a very nice tutorial https://wiki.archlinux.org/index.php/systemd. Your basic command for managing systemd is systemctl:
systemctl status NAME_OF_SERVICE
systemctl stop NAME_OF_SERVICE
systemctl start NAME_OF_SERVICE
systemctl disable NAME_OF_SERVICE
systemctl enable NAME_OF_SERVICE
systemctl mask NAME_OF_SERVICE (permanently disable service)
systemctl unmask NAME_OF_SERVICE
systemctl can not only reboot the computer but put it to sleep or power it off:
Linux: how to write your own systemd scripts (unit files)
Case 1: You want to start your own server processes via systemd.
are simply started as:
your_cmd 1 &
your_cmd 2 &
your_cmd 3 &
There is no overall daemon that supervises everything.
To stop this process you would run
To integrate this very primitive service to systemd you write two scripts.
One script for startup and one to stop the processes:
# This is /usr/bin/your_cmd-start.sh
# start script for your_cmd
your_cmd 1 &
your_cmd 2 &
your_cmd 3 &
# This is /usr/bin/your_cmd-stop.sh
# stop script for your_cmd
killall -w your_cmd
This is the basic framework of our process and it could be any simple script based server process. It does not really matter what it exactly does. The important part is that there is a script to start it and after having executed that script the process is running. There is as well a script to stop the whole thing.
To integrate this into systemd you write a short text file called unit file and
you copy this file to /usr/lib/systemd/system/. The file name must end in .service:
The content of this file must look like this:
# this is /usr/lib/systemd/system/your_cmd.service
Description=your_cmd server daemon
# see man systemd.service
You can syntax check it with:
systemd-analyze verify /usr/lib/systemd/system/your_cmd.service
There are two important keywords in the unit file: Type=oneshot means that this
is a script which just runs and then exits and RemainAfterExit=true
means that although the script has finished the service is still running.
Now enable it:
systemctl list-unit-files | grep your_cmd
systemctl enable your_cmd
systemctl start your_cmd
systemctl status your_cmd
To stop it:
systemctl list-units | grep your_cmd
systemctl stop your_cmd
Case 2: You want to do some configuration tasks and execute those commands at startup.
This is very similar to the first case but there is no server process. You want to change some settings before a given service starts. In this example we want to run a script before httpd starts.
# This is /usr/bin/your_config-start.sh
# do all your commands here... script terminates when all is done.
You would write the following unit file and activate that service in the same way as in the above case. There is just no stop command.
# this is /usr/lib/systemd/system/your_config.service
# enable with command: systemctl enable your_config
# man systemd.unit
# see man systemd.service, systemd.exec
I hated systemd for a few days but after I figured out how to use it
and how to add my own customizations it was not too bad.
It works actually quite well. You just have to learn how to use it.
Copyright © 2004-2017 Guido Socher