When a Linux system is booted, we want certain processes to run immediately.
In the old days, that is 25 years ago or so, this was done in „BSD-style“ by having certain magical shell scripts that start everything in the right order. When adding another service, this just had to be added to the shell script and that was it.
Then this was replaced by System-V-style init. So the system had certain runlevels. The desired runlevel was configured somewhere. And for each runlevel there was a directory which contained a lot of scripts or mostly softlinks to scripts. The scripts starting with S were used for starting and the scripts with K were used for stopping. The ordering was achieved by adding a two digit number immediately after the letter S or K.
Important runlevels were:
- single user mode, which is a very special way to boot the system for maintenance tasks that cannot otherwise be achieved. I have used this only a few times in my life when the system was really seriously messed up…
- multi user mode with network and no graphical UI. This is what most servers are running
- multi user mode with graphical UI. This is what most Laptops are running
It was possible to boot into a certain runlevel by configuration. And to switch to another runlevel…
Now this has given way to another more versatile and approach called systemd.
Processes that need to be started are configured by a so called service file. It contains information about how to start and stop the process and about dependencies on other services or abstract groups called „target“. Runlevels are expressed as targets and have names instead of numbers.
A service can be enabled by
systemctl enable something.service
which means it will be started automatically when booting.
It can be disabled with
systemctl disable something.service
And it can be started and stopped with
systemctl start something.service
systemctl stop something.service
The status is queried with
systemctl status something.service
There is a lot more to discover… For example, there are timers to run a certain task repeatedly (instead of putting it into crontab).
If you need to shutdown or start a service at certain times, it is a good idea to perform this always via systemctl and call systemctl from the script instead of going directly to the startup script of the process, because systemctl start/stop stores information that allow systemctl status to work.
It should be observed, that systemctl not only calls scripts to start and stop services, but also keeps track of the processes that are created by this. So it is very important to always start and stop them via systemctl and not to bypass this.
It is nice how beautiful and consistent this solution is compared to the previous solutions…
