System V, systemd and Upstart

Controlling Linux Services

Init Process


The init process on Linux systems is commonly known as the mother of all processes. The "init" process will always have a Process ID of "1" (pid of 1), it is the first process started by the kernel on your system. init is short for initialization and is used to start all other processes and your default runlevel. Overtime many distributions have adopted the System V standard for managing services, however, other distributions have moved to "Systemd" or "Upstart".


SysV - System V


If your Linux distribution uses the "SysV" standards, then init will examine a file called "/etc/inittab. This file contains your default runlevel that the system should start under. For example "id:3:initdefault:" would automatically start all the scripts in the runlevel 3 directory structures.

Run Level 1 - Single User Mode
Run Level 2 - Same as runlevel 3, but without NFS
Run Level 3 - Multi-user and networking mode
Run Level 4 - Unused
Run Level 5 - Same as runlevel 3, but with graphical desktop (X window System)

For more information on the boot process: Booting Linux





Running "System V" init scripts


Quite often as an administrator you will need to stop, start, restart or reload a particular service/daemon. To do this we use a command called "service". This command allows you to execute "System V" scripts that are normally located within the "/etc/init.d" directory. As well as being able to start and stop a service/daemon, we can also view the current status.


service command examples


Status Check: Here we are requesting the current status of the "sshd" daemon



[root@centos etc]# service sshd status
openssh-daemon (pid  1599) is running...

Status Check on all Processes: Runs all of your init scripts in alphabetical order with the status option. Below is an extract of the output from this command:



[root@centos ~]# service --status-all
abrt-ccpp hook is installed
abrtd (pid  1708) is running...
abrt-dump-oops (pid 1716) is running...
acpid (pid  1487) is running...
atd (pid  1740) is running...
auditd (pid  1262) is running...
automount (pid  1571) is running...
avahi-daemon (pid  1375) is running...
Usage: /etc/init.d/bluetooth {start|stop}
certmonger (pid  1752) is running...
cpuspeed is stopped
crond (pid  1724) is running...
cupsd (pid  1476) is running...
dnsmasq is stopped
firstboot is not scheduled to run
hald (pid  1496) is running...

Stop: Here we requested that the "sshd" daemon should stop. The status option was also issued to check the new status.



[root@centos etc]# service sshd stop
Stopping sshd:                                             [  OK  ]

[root@centos etc]# service sshd status
openssh-daemon is stopped

Start: This time we are requesting the "sshd" should be started.



[root@centos etc]# service sshd start
Starting sshd:                                             [  OK  ]

Restart: This time we are going to "bounce" the "sshd" daemon (stop and then immediately restart).



[root@centos etc]# service sshd restart
Stopping sshd:                                             [  OK  ]
Starting sshd:                                             [  OK  ]

Reload: The "reload" option is very useful if you have made changes to a configuration file and you want to bring these changes in.



[root@centos etc]# service sshd reload
Reloading sshd:                                            [  OK  ]

Upstart


Upstart is an event based replacement for the "init" daemon. Upstart was written by a former employee of the well known company that provides us with Ubuntu (Canonical). The idea behind Upstart was to move away from the traditional start process whereby tasks that were started had to complete before the next task could start. Upstart is an event driven system that allows it to respond to system events asynchronously. Upstart is responsible for starting and stopping of services and tasks at boot and shutdown. It also actively monitors these services and tasks. Upstart is also able to run sysvinit scripts without modification. Various distributions have included Upstart as a replacement for System V. These have included RHEL, CentOS, Fedora. However, many of these systems have now moved to "systemd"

As we saw earlier, we can control services/daemons with the "service" command under System V, however, under Upstart we use a different command. The command that is used with Upstart is "initctl". This command allows you to communicate with the init daemon. Below are some basic examples of the "initctl" command in use.



initctl command examples


Status Check: This option requests the status of the specified job.



root@john-desktop:~# initctl status cups
cups start/running, process 672

The job name is given first followed by the current goal and state of the instance and then the process id number.

Stop: The "stop" option specifies that the desired state should be "stopped".



root@john-desktop:~# initctl stop cups
cups stop/waiting

Start: The "start" option will start a new instance of the specified job.



root@john-desktop:~# initctl start cups
cups start/running, process 3574

Restart: This option will restart that the specified job is restarted. The instance that is restarted will retain its original configuration.



root@john-desktop:~# initctl restart cups
cups start/running, process 3606

Reload: This option will reload the specified instance.



root@john-desktop:~# initctl reload cups

List: List requests that all jobs/instances and their associated status is displayed. Below is an exert from the output of this command:



root@john-desktop:~# initctl list
avahi-daemon start/running, process 611
mountall-net stop/waiting
nmbd stop/waiting
passwd stop/waiting
rc stop/waiting
rsyslog start/running, process 601
tty4 start/running, process 1080
udev start/running, process 437
upstart-udev-bridge start/running, process 429

Reload Configuration: This option requests that the init daemon reloads its configuration files. No jobs are restarted by this command.



root@john-desktop:~# initctl reload-configuration cups

Under normal circumstances, you should not need to issue the above reload command as "init" watches its configuration directories with "inotify" and automatically reloads in cases of a change.


systemd


systemd is another replacement to System V. systemd stands for system daemon. Its name is intentionally in lowercase! systemd was designed to allow for better handling of dependencies and have the ability to handle more work in parallel at startup. systemd supports snapshotting of your system and the restoring of your systems state, keeps track of processes stored in what is known as a "cgroup" as opposed to the conventional "PID" method. systemd is now been taken up by many popular Linux distributions. Fedora, Mandriva, Mageia, Arch Linux. There are also plans for systemd to be included in newer releases of RHEL (Red hat).

As we saw with "System V" and "Upstart" both types have their own unique command for controlling services. The same applies for systemd. The command that is used under systemd is "systemctl". Below are a few examples of some of the basic functionality of the "systemctl" command.


systemd command Description
systemctl start mytest.service Starts specified service
systemctl stop mytest.service Stops specified service
systemctl status mytest.service Request status of specified service
systemctl list-unit-files --type=service Lists known services that can be started or stopped
systemctl restart mytest.service Starts and then stops specified service
systemctl reload mytest.service If supported will reload the configuration files
systemctl enable mytest.service Equivalent to chkconfig mytest on
systemctl disable mytest.service Equivalent to chkconfig mytest off
systemctl is-enabled mytest.service Checks to see if service is configured to start in current runlevel