A few videos back, when we were talking about managing the boot process, we briefly explored the history of Linux process management through init (SysVinit), Ubuntu's Upstart, and the now dominant systemd. In this video, we're going to see all three in action through the way they control system runlevels.

Controlling Linux system runlevels

A runlevel defines the operating system resources and access that are made available at a given time. Runlevel 0 will remove all access by shutting down the system altogether, while runlevel 3 will provide full access to all resources - depending of authorization, of course.

In the old init system, the default system runlevel was defined by an entry in the /etc/inittab file. The first line in this snippet - id:3:initdefault - sets the runlevel to 3.

Most Linux distributions no longer rely on the inittab file - something that's a source of great confusion considering the wealth of older documentation that can still be found around the Internet and in book stores. Ubuntu's Upstart hides its default runlevel definition in the rc-sysinit.conf file within the /etc/init/ directory. The entry that interests us will look something like env DEFAULT_RUNLEVEL=2.

Upstart also uses scripts that, when run, control the behavior of specific services. Scripts compatible with older SysVinit processes can be found in /etc/init.d, while scripts used by Upstart processes are found in /etc/init/

How systemd controls the Linux environment

While you have to know all these details for the LPIC exam - and in case you're called on to work with older systems, as we've already meantioned, the clock is ticking on the relevance of init and Upstart, as the world is moving to systemd.

So let's talk about systemd. For this shell session, we've left Ubuntu behind and are now enjoying Fedora - the earliest major distribution to adopt systemd. We'll begin by noting that systemd itself doesn't focus directly on overall system runlevels, but on the status of specific processes. Systemd works with files called Units, each of which describes in plain text a service, device, socket, or mountpoint.

We can manually manage units in the /etc/systemd/system directory, while packages install their unit files in /usr/lib/systemd/system. As an example, let's take a look at /usr/lib/systemd/system/tmp.mount which points to an available temporary directory created as a virtual tmpfs where other processes can safely dump their short-term data. The location of this directory is /tmp - a common directory that most Linux processes expect to be able to access.

Systemd comes with a couple of really useful tools to help diagnose boot problems: systemd-analyze tells you how long - in seconds - each part of the startup process took. You can obviously use this to narrow down your search for whatever it might be that's taking more time than it should. Systemd-analyze blame will show you now long - in miliseconds - each specific unit - whether a service, mount, or socket - took to load.

However, the command line utility that does most of the heavy lifting for systemd is systemctl. To give you an idea how this works, we'll play with just a few examples here. systemctl list-units will, as you might expect, list key information about all the units that are currently running. Since the list is quite long, you might want to narrow down your search using your old friend grep:

Let's try activating a service. We'll use the Apache webserver, known in the Fedora world as httpd. Since Apache is a service, we'll identify it by appending .service to its name. First, let's see if it's running already. It's not. Next we'll use the enable command to instruct systemd to run Apache each time the system boots. But that won't get it going until we actually restart the system. If we just can't wait, we'll use start to launch Apache right away. And just to confirm that it is actually functional, we'll run list-units once more, again grepping for httpd

It looks good.

That's pretty much what you'll need to know about systemd for the LPIC exam. Let's review. systemd manages services, mountpoints, devices, and sockets through text files kept in either /etc/systemd/system or /usr/lib/systemd/system/. systemd-analyze will display each part of the startup process took, and systemd-analyze blame breaks that down further to the service level. systemctl list-units will display all running processes, systemctl enable will force a process to load at start-up, systemctl start will start a specified process immediately and, while we're on the topic, systemctl stop will stop a specified service.

Now we can return to Ubuntu to describe the ways you can control system wide runlevels that are universal to all process managers. In a previous video we showed how, by pressing "e" from the GRUB menu, we would be able to edit the boot parameters. So, to illustrate, by adding the word "single" to the end of the kernel command line, Linux will start up in single-user mode rather than multi-user. Single-user mode is often helpful for emergency recovery efforts. You can achieve the same result from the command line of a running session with telinit 1 - for which you'll need admin powers. You can power down the system using telinit 0, or sudo shutdown -h now - where "h" stands for "halt" and "now" tells Linux to close up shop immediately.

The only runlevel-related topic left to cover is communications. It's all very nice to have the power to control processes and to shutdown powerful servers, but you're not going to make a lot of friends if you don't warn all the other users who happen to be logged in from their own terminal sessions and doing their work.

Assuming that all logged in users are actually looking at their terminals when you run a telinit or shutdown command - and, considering how many windows most people can have open at a given time, that's not necessarily a particularly strong assumption - Linux will automatically send a warning for you.

I'll demonstrate how this works while logged in to two separate user accounts on a single LXC container. The larger window in the background is logged in as the normal user Tony, and the smaller window in the foreground is an admin user. This way we can simultaneously watch the terminals of both. As admin, I'll run sudo shutdown -h 2 ...which will halt the system in two minutes. Notice how the shutdown message is displayed for both accounts. Because I don't really want to shutdown in two mintues, I'll hit ctrl-c to cancel the action.

Now, besides messages that will automatically accompany shutdown (or telinit) commands, Linux also provides "wall" to permit communication between users. In truth, while the LPIC exam is mostly interested in wall as a tool to keep your users up to date on your nefarious plans to change their work environment, it can also be used for more general communications. I've created a text file that I will read using cat but, instead of displaying it to the screen, I'll pipe it to wall, which will send it to the screen of every user currently logged in. I guess you can think of "wall" as kind of a prehistoric social networking tool.

To review, adding an argument (like single) to the kernel command line in GRUB will control its startup mode. telinit and shutdown offer similar control from the command line of a running machine. You can schedule a shutdown or reboot using something like sudo shutdown -r 5 - which will cause a reboot in five minutes. And piping a text file to wall will display text to all logged in users.