Introduction To The Topic

In the old days the operating system was loaded by a boot loader and it ran processes. But when you started your computer, which processes it ran was still an unanswered question. Usually once the kernel was running it would then run /sbin/init (or whatever you specified as the argument to the kernel option init=) which would be responsible for doing whatever needed to be done. If you just needed a single program to run and nothing else to happen, you could just make the init file be that program and you were done. But people wanted fancy things with server daemons running in the background as soon as the machine started. Complex systems of scripts and software evolved to handle this. One of the first of these was System V R4 which was reasonably straight forward for people who understood shell scripting.

Today, however, classic sysvinit is seen by many has having many intolerable deficiencies. There has been a profusion of new initialization systems. What is incredibly annoying and intolerable to me is that the main advantage of sysvinit, the fact that we all knew it, is being discarded so carelessly. This means that doing simple things to Linux computers is no longer a simple thing. Because we’re not talking about a single new way to do things simply learning the new way is not sufficient. These notes will be to collect and organize what I need to know about these diverse systems.

The Different Systems

Resources

How To Tell You’re Using It

I’m not the only one to have ever asked this question.

Since the initialization system is always the first thing run, it is always process number 1. So the first thing to check is this.

sudo stat /proc/1/exe

Maybe the package manager for the distribution can help.

dpkg -S /sbin/init
yum provides /sbin/init
Gentoo
  $ equery b /sbin/init
  * Searching for /sbin/init ...
  sys-apps/sysvinit-2.88-r7 (/sbin/init)

Upstart

Centos 6
$ cat /etc/system-release; sudo stat /proc/1/exe | head -n1
CentOS release 6.7 (Final)
  File: `/proc/1/exe' -> `/sbin/init'
$ yum provides /sbin/init | grep -B1 installed
upstart-0.6.5-13.el6_5.3.x86_64 : An event-driven init system
Repo        : installed
$ initctl version
init (upstart 0.6.5)

This is very, very similar on AWS.

Amazon Linux AMI release 2016.03
upstart-0.6.5-13.3.13.amzn1.x86_64 : An event-driven init system

systemd

An interesting talk about systemd and various balanced perspectives on it.

Centos 7
$ cat /etc/system-release; sudo stat /proc/1/exe | head -n1
CentOS Linux release 7.2.1511 (Core)
  File: '/proc/1/exe' -> '/usr/lib/systemd/systemd'

$ head -n1 /etc/inittab
# inittab is no longer used when using systemd.

$ file /run/systemd/system/
/run/systemd/system/: directory

Note too that I’ve found one of these on Centos 7

/.readahead

Here’s some perspective on that.

Debian 8
$ cat /etc/issue
Debian GNU/Linux 8 \n \l

$ file /sbin/init
/sbin/init: symbolic link to /lib/systemd/systemd

Also check for the existence of this directory /run/systemd/system. Apparently systemd creates the /run directory so the existence of such a system directory is nearly certain proof that it is systemd.

Distributions Which Use It By Default

  • Debian - ?

  • Red Hat/Centos 6 - Upstart (with sysvinit style scripts).

  • Red Hat/Centos 7 - systemd

  • Gentoo - OpenRC

  • BSD - OpenRC or BSD init (like sysvinit)

  • Ubuntu - Upstart

  • Solaris - SMF

  • MacOSX - launchd

How To Start/Stop/Check A Service

Check my CentOS notes for a complete example of starting a simple server. That guide should be useful for sysvinit and systemd.

sysvinit

service --status-all
service exampled {start,stop,restart,reload,condrestart,status}
/etc/init.d/exampled {start,stop,restart,reload,condrestart,status}

Upstart

/etc/init.d/exampled {start,stop,restart,reload,condrestart,status}
{start,stop,restart} exampled
initctl {start,stop,restart} exampled

From the man page of initctl, "… allows a system administrator to communicate and interact with the Upstart init(8) daemon."

systemd

From the systemctl man page, "may be used to introspect and control the state of the systemd(1) system and service manager."

systemctl {start,stop,restart,reload,condrestart,status} exampled

To get a full list of the services and see which are disabled and which are enabled, try this.

sudo systemctl list-unit-files

How To Add/Remove A Service From Run Level

sysvinit

I have to say, I always did think that chkconfig was a terrible name for this command.

chkconfig --list
chkconfig exampld {on,off,--list}

systemd

Note that on some systemd installations, the chkconfig scripts will continue to work.

ls /etc/systemd/system/*.wants/
systemctl {enable,disable} exampled

Gentoo Specific

From the man page for rc-config.

eselect rc [help|usage|version]
eselect rc add script [runlevel...]
eselect rc delete script [runlevel...]
eselect rc list [runlevel]
eselect rc pause script [script...]
eselect rc restart script [script...]
eselect rc show [runlevel...]
eselect rc start script [script...]
eselect rc stop script [script...]

Run Levels

Note that run levels might be different too. This is important, for example, when trying to turn off graphics in order to run a video driver installer.

Instead of init 3 Systemd now has this.

systemctl isolate multi-user.target
systemctl isolate runlevel3.target

ANd for init 5.

systemctl isolate graphical.target
systemctl isolate runlevel5.target

What runlevel is the system using?

systemctl list-units --type=target

How to add your own init scripts

This relates to AWS which had some upstart facade (maybe) over what behaved like sysvinit.

cd /home/ec2-user/isbd/isbd_server/init/
vim isbdd_starter
chmod 755 isbdd_starter
cd /etc/init.d/
sudo ln -s /home/ec2-user/isbd/isbd_server/init/isbdd_starter isbdd
./isbdd_starter status
./isbdd_starter stop
./isbdd_starter start
service isbdd status
service isbdd restart
service isbdd start
chkconfig --add isbdd
chkconfig --list isbdd

Here’s another way that might work. Create a file like this.

:->[ubuntu][~]$ cat /lib/systemd/system/myexample.service
[Unit]
Description=Pi Status Lights
After=multi-user.target

[Service]
Type=forking
ExecStart=/bin/bash /bin/true
Restart=restart-always
Nice=19

[Install]
WantedBy=multi-user.target
:->[ubuntu][~]$ systemctl status myexample
● myexample.service - Pi Status Lights
   Loaded: loaded (/lib/systemd/system/myexample.service; disabled; vendor preset: enabled)
   Active: inactive (dead)
:-<

The "Type=" might also be…

  • idle - don’t know exactly but the name is suggestive

  • simple - like idle

  • oneshot - e.g. for fsck type things

  • forking - classic simple daemons, probably the right one for normal custom purposes.

  • dbus - fancy system managed things

The "Restart=" and "Nice=" lines are optional.

Details about this kind of thing. Or check man systemd.service or man systemd.unit.

Predictable Network Device Names

Predictable? Ya, right.

Systemd does some new and overly helpful things with device names meaning what you used to know as eth0 is now enp14s0. Here are some links to discussions about that.