A Belated Introduction to Linux Runlevels

Linux RunlevelsI’ve read books and watched tutorials on the subject of Linux, that start right out with runlevels, do a good job of explaining the init feature, and manage to loose me in a state of confusion and despair.

What I did learn, very early on, was that I could use Linux and get along just fine without understanding runlevels at all, thank you very much.

At the same time, there was always a little voice at the back of my head, telling me that unless I understood what appears to be one of the most fundamental principles of the operating system that I’m trying to learn, then why I am bothering to try?

Guess what? I looked into runlevels, and on one level — pun intended — I now understand them. Now I can continue to live, with runlevels functioning quietly in the background, without giving them a second thought.

If anyone else is in the same boat as I once was, read on. You might just learn enough to be able to appreciate their quiet efficiency.


A runlevel is a state of operation that determines what mode a machine will run in, and thus what system services are operational.

The runlevel is determined when a machine is first booted up, and although it can be changed, only one runlevel can function at a time.

There are 7 runlevels, numbered 0-6, and although there are some standards and similarities, the order and function of each runlevel may differ between each Linux distributions.

The Fedora runlevels are:

0 System Halt
1 Single User
2 Multiple Users (No Network Filesystem)
3 Multiple Users, Command Line Only
4 User-Definable
5 Multiple Users, Graphical User Interface
6 Reboot

After looking through this list, it should become evident that a server may be set up with a default runlevel of 3, and a PC with a default runlevel of 5.

Switching the runlevel will alter the state of the system, and cause various services to start or stop, as the case may be.


In the past, a program called init (short for initiation) was used to control runlevels.

It worked in conjunction with telinit, which was used to change the system runlevel, and service, which ran init scripts.

Now, however, init is being phased out of the picture by many distributions of Linux (including Fedora), and being replaced, in most cases, with systemd.

Systemd uses “targets” in place of runlevels, and systemctl in place of systemd, etc.

What this means is very simple: runlevels are no longer relevant. In fact, they’re pretty much obsolete.

I’m late to the party again. *Sigh*

Shutting Down & Rebooting

Changing the runlevel state of a machine when it is already running — as opposed to at boot time — is a rather drastic move, and one which I would recommend saving for desperate times that deserve desperate measures.

An abrupt runlevel change on a multi-user machine, for example, could generate problems for anyone that may not have been informed of the change in advance.

The shutdown, halt and reboot commands allow for a more gentle transition to runlevels 0 and 6, by preventing new logins and allowing you to send a message informing currently-logged-in users that shutdown is imminent. You can even schedule a shutdown so that some time is given to allow work to be saved, and processes to be terminated safely.

shutdown 15 because i decided now would be a good time to test

The above example will initiate a system shutdown (add the -r option to reboot instead) in 15 minutes, and send a wall message to each user in the meantime that states “because i decided now would be a good time to test”. The system will, after 15 minutes, be safely shut down.

The shutdown time can be specified in a hh:mm format, or with the number of minutes until shutdown, or by saying “now”.


I learned about runlevels long after they went out of style, but in the process, I learned enough about systemd to make the research worth my while.

Next up I plan to go into detail about systemd, and the various ways to make use of it.

Leave a Reply

You have to agree to the comment policy.