init vs systemd

Details

Last Updated: Sunday, 18 July 2021 15:38

Published: Tuesday, 05 November 2019 01:24

Hits: 4066

In the startup sequence discussed before, we saw that init was the first process to start. However, on newer linux versions, init has been replaced by systemd (system mgmt daemon, d represents daemon) as the first process to start. Init was based on old SysVInit, while systemd is based on newer SystemD, This is a very good link explaining it:

https://www.tecmint.com/systemd-replaces-init-in-linux/

/bin/systemd is run instead of /sbin/init as the process with PID=1. Purpose is the same. A systemd, may refer to all the packages, utilities and libraries around daemon, instaead of just the daemon. However, on my Linux Mint 18, and other linux distro, I still see init as the first process to start, even though systemd is enabled.

Init and systemd have different ways of calling on a service (such as apache2, ssh, cron, etc). This link, explains diff b/w diff methods: https://askubuntu.com/questions/911525/difference-between-systemctl-init-d-and-service

There are 3 different methods:

1. SysVInit using init.d: Under init method, init scripts would be written for any service, and placed in /etc/init.d dir. Then the script in init.d dir would be called directly with options to start/stop/restart/etc for that service. This is not used anymore on new Linux distro, so no need to learn this anymore. It's mentioned briefly below, in case you encounter this on some systems (as Ubuntu).

Selected scripts in /etc/init.d dir are run at startup automatically. Whether the scripts in init.d dir should be run or not is decided by symbolic links to these scripts stored in various dir in /etc/rc*.d/ (rcS.d, rc0.d, ... rc6.d). dir rcS.d has all symlinks in it starting with S where "S" indicate that the service should be started. rc0.d has symlinks starting with S or K where "K" indicate that the service should be stopped (killed). These scripts in rc0.d are executed for runlevel0. Similarly rc1.d is for runlevel1 and so on. The default runlevel for Ubuntu is 2. 

In CentOS 6, this is what I see in dir: /etc/rc.d/rc2.d/

S10network -> ../init.d/network
K50netconsole -> ../init.d/netconsole

This indicats that "network" pgm would be started at startup, while "netconsole" won't.

If we want to add a new pgm to start at startup, we don't modify the links directly, but run "update-rc.d" to update the links to enable/disable pgm.

ex: sudo update-rc.d <pgm1> enable => This updates symlinks to remove "K" symlinks and replaces them with "S" symlinks for program "pgm1". So, now pgm1 would start by default at startup

ex: sudo update-rc.d <pgm1> disable => This updates symlinks to remove "S" symlinks and replaces them with "K" symlinks for program "pgm1". So, now pgm1 would not start by default at startup

NOTE: On most new installation of any Linux distro, you won't see any files in /etc/init.d/ as those files have moved to systemd. On CentOS 6, I don't see any pgm in /etc/init.d, while on Linux Mint 19 (Tara), I see about 50 or so pgms as apache2, bluetooth, sql, etc in that dir. This indicates that many pgms still install files in /etc/init.d/ to control their startup behaviour. In CentOS 6, I do see a README in /etc/init.d/README stating that all the files have moved. However, do note that on many linux distro, traditional init scripts continue to function on a systemd system (even though all the files have moved to systemd). An init script /etc/rc.d/init.d/foobar is implicitly mapped into a service unit foobar.service during system initialization. This is to maintain compatibility, so that existing scripts or any new scripts in /etc/init.d/ don't suddenly stop working.

ex: /etc/init.d/apache2 status => Here, apache2 process init script is called to check status of apache2

2. SysVinit using service: Later on, service cmd was used for SysVinit based systems. It was intended to provide smoother transition into system dependency handling. In most cases,  this newer service cmd just linked scripts in /etc/init.d dir, while in some cases, it called scripts located in entirely diff dir. However, this method is not supported by all Linux distro, and most newer programs, don't even provide support for service. It's mostly there for legacy purpose, and should be avoided all together.

ex: sudo service apach2 status => may work on some distro

3. SystemD using systemctl: This is the newer method of controlling services. Earlier Linux OS used init system, whose fundamental purpose was to init the components that must be started after Linux kernel is booted, and then manage services and daemons. Now, most Linux distro have switched to using systemd, instead of init. However systemd also does same tasks as what "init" used to do. Moving forward, this is the only method that will be supported on all Linux systems. All others will be deprecated. So, use this as preferred method on newer Linux distro, that support it.

link with syntax of systemctl: https://www.digitalocean.com/community/tutorials/how-to-use-systemctl-to-manage-systemd-services-and-units

systemctl => cmd to control systemd "system and services manager". It can be used to enable, start, stop, check status of system services as sshd, httpd, etc.

/etc/systemd/ => contains all systemd config files. systemd looks in /etc/systemd/system/<some_target>.target.wants file for autostart of any systemd application. We see such files for applications as basic, graphical, bluetooth, getty, network, sysinit, multi-user, etc. Each target is dependent on bunch of services that it runs. symbolic links for *.service files are created here from below dir, whenever we want to autostart any service at boot.

/usr/lib/systemd/system/*.service => This has service file for applications as gdm, bluetooth, NetworkManager, etc, target, wants, etc.

/lib/systemd/system/ => has all units as service, target, wants, etc. This is basically replica of above dir. This is where systemctl looks for, so whatever program is in this dir, is what is supported by systemctl ??

ex: sudo systemctl status apache2.service => This works on all systems supporting systemd. Here, it looks for file "/lib/systemd/system/apache2.service"

ex: sudo systemctl status apache2 =>Here, we omitted the extension, .service, but it still works, as by default, systemctl cmd looks for .service file.

 Some systemd cmds for xinit/graphical services are explained in "Linux Installation".

.