systemd vs sysvinit part 1
For a quick and dirty cheatsheet, see my other post
Differences between systemd and sysvinit (a.k.a init) - Part 1
During your system startup, once your boot-loader (e.g. grub) has finished loading the kernel and ram-disk, it will handover control to a "service manager" to make sure that certain services / daemons are running. systemd and sysvinit are those "service managers".
While sysvinit (or simply init) has been around for a long time, the recent Linux distro's (from Debian 7, RedHat / CentOs 7, Ubntu 15 and CoreOS) have adopted the systemd approach.
Here in part 1, I will give an overview of how the system starts up and how the services are managed in sysvinit. In part 2, I will give an overview of how this has changed with systemd.
SysVInit - Boot process
In sysvinit, there is a concept of runlevel. A runlevel is a mode in which your system operates, such as 3 = full multiuser-mode, 5 = graphical mode etc.. Just think of it like the "Windows safe mode" being different from the normal mode, where the safe mode will have less features / programs available to you than the normal mode.
You can find the runlevels in /etc/inittab. That is also where you can set a default runlevel. In my case, I see the following line at the bottom of my file:
This indicates that my default runlevel is 3 (Multiuser mode with networking). That would also be the case for most servers.
Every runlevel has its own directory, such as /etc/rc3.d/ (for runlevel 3). If you look at the files in these directories, they all start with either K or S, followed by a number, then by the name of a service, e.g. S64mysqld. Apart from that, they are all symlinks to scripts in /etc/init.d/, where scripts reside to start/stop/restart/reload your services. The numbers in these filenames represent the order in which these scripts get executed. Here is a selection of files (symlinks) that I have in /etc/rc3.d
[root@vagrant-centos64 vagrant]# ls /etc/rc3.d/ lrwxrwxrwx. 1 root root 19 Oct 30 2013 K10saslauthd -> ../init.d/saslauthd lrwxrwxrwx. 1 root root 18 Oct 30 2013 K15svnserve -> ../init.d/svnserve lrwxrwxrwx. 1 root root 17 Oct 30 2013 K30postfix -> ../init.d/postfix lrwxrwxrwx. 1 root root 20 Oct 30 2013 K50netconsole -> ../init.d/netconsole lrwxrwxrwx 1 root root 13 Jan 18 2014 K60nfs -> ../init.d/nfs lrwxrwxrwx 1 root root 20 Jan 18 2014 K69rpcsvcgssd -> ../init.d/rpcsvcgssd lrwxrwxrwx 1 root root 20 Jan 18 2014 K87multipathd -> ../init.d/multipathd lrwxrwxrwx. 1 root root 21 Oct 30 2013 K87restorecond -> ../init.d/restorecond lrwxrwxrwx. 1 root root 15 Oct 30 2013 K89rdisc -> ../init.d/rdisc lrwxrwxrwx 1 root root 22 Jan 18 2014 S02lvm2-monitor -> ../init.d/lvm2-monitor lrwxrwxrwx 1 root root 19 Jan 18 2014 S08ip6tables -> ../init.d/ip6tables lrwxrwxrwx 1 root root 18 Jan 18 2014 S08iptables -> ../init.d/iptables lrwxrwxrwx 1 root root 17 Jan 18 2014 S10network -> ../init.d/network lrwxrwxrwx 1 root root 17 Jan 18 2014 S12rsyslog -> ../init.d/rsyslog lrwxrwxrwx 1 root root 19 Jan 18 2014 S55memcached -> ../init.d/memcached lrwxrwxrwx 1 root root 14 Jan 18 2014 S55sshd -> ../init.d/sshd lrwxrwxrwx 1 root root 16 Jan 18 2014 S64mysqld -> ../init.d/mysqld
When your system boots up, the first process (pid 1) is /sbin/init, then it finds the default runlevel in /etc/inittab. Based on that runlevel number, it navigates to the runlevel directory for that number (/etc/rc3.d/ in my case). Once there, it runs the K-scripts with a stop option and then run the S-scripts with a start option. These scripts are run sequentially in the order to which they are numbered. Once it has run all the K- and S-scripts, your system is then ready with all processes running that you need within that runlevel.
SysVInit - Enable service at startup
So you might wonder: "How do these symlinks land in the runlevel directories?" and "What if I want to enable a service at startup?"
In sysvinit, that is done by
chkconfig. Let's say you have installed nginx and you want to enable it at startup:
[root@vagrant-centos64 vagrant]# chkconfig nginx on [root@vagrant-centos64 vagrant]# chkconfig | grep nginx nginx 0:off 1:off 2:on 3:on 4:on 5:on 6:off
With the first command, we have enabled nginx at startup. With the second command, we check for which runlevels we have enabled nginx at startup. It shows 2,3,4 and 5. This is the default behaviour for
chkconfig <service> on when we leave out the --level option.
If we look at our /etc/rc3.d/ directory, we will see that a S-script has been added for nginx, same for the other directories where nginx has been enabled. However, if we look at the runlevel directories 0,6, for which nginx has been disabled (see output chkconfig above), we will see that a K-script has been created for nginx.
[root@vagrant-centos64 vagrant]# ls -l /etc/rc3.d/ | grep nginx lrwxrwxrwx 1 root root 15 May 12 11:30 S85nginx -> ../init.d/nginx [root@vagrant-centos64 vagrant]# ls -l /etc/rc0.d/ | grep nginx lrwxrwxrwx 1 root root 15 May 12 10:51 K15nginx -> ../init.d/nginx
SysVInit - service command
Please bear in mind that chkconfig is only meant to make sure that certain services are started and stopped when you change into another runlevel, such as when you boot up your system or by
telinit. chkconfig does not start a service or stop a service for you on the spot. For that, you need the
[root@vagrant-centos64 vagrant]# service nginx start Starting nginx: [ OK ]
SysVInit - Change runlevels
You would hardly ever change the runlevel while your system is running. But as a system administrator, there might be times that you want to switch to the single-user mode (runlevel 1) to perform some administrative tasks. You can change runlevel through the
init command (which has pid 1) or through
telinit, which tells init to change runlevel. To find the current runlevel, you can use the
runlevel command or
[root@vagrant-centos64 vagrant]# telinit 1 [root@vagrant-centos64 vagrant]# who -r run-level 1 2016-05-13 08:36 last=3