Linux Run Levels

There’s more than one way to run a Linux computer. And, coming from the rough and tumble open source world as Linux does, there’s more than one way to  control  the multiple ways you can run a Linux computer. I’ll get back to that in just a minute or two.  But let’s start at the beginning. One of Linux’s greatest strengths is the ability for multiple users to log in and work simultaneously on a single server. This permits all kinds of savings in cost and labor and, to a large degree, is what lies behind the incredible flexibility of container virtualization.  However, there may be times when you just want to be alone. Perhaps something’s gone badly wrong and you have to track it down and fix it before it gets worse. You don’t need a bunch of your friends splashing around in the same pool while you work. Or maybe you suspect that your system has been compromised and there are unauthorized users lurking about. Whatever the case, you might sometimes want to temporarily change the way Linux behaves.  Linux run levels allow you to define whether your OS will be available for everyone or just a single admin user, or whether it will provide network services or graphic desktop support. Technically speaking, shutting down and rebooting your computer are also done through their own run levels.  While you will find minor differences among Linux distributions, here are the standard run levels and their designated numbers:
B oot parameter:
0: Halt
1: Single user mode
2: Multi-user, without NFS
3: Full multi-user mode
4: Unused
5: X11
6  : Reboot
R un levels can be invoked from the command line using either init or telinit. Running
init 6

for instance, would cause your computer to reboot. On some distributions, you can also use commands like “shutdown” to—well—shut down. Thus:

sudo shutdown -h now

would halt (“h”) a system right away and

sudo shutdown -h 5

would shut down the system, but only after 5 minutes, and

sudo shutdown -r now

would reboot.  Incidentally, since there might be other users logged into the system at the time you decide to change the run level, the shutdown command will automatically send a message to the terminals of all other logged in users, warning them of the coming change.  You can also send messages between terminals using the wall command (these messages will, of course, not reach graphical user interface [GUI] desktop users). So suppose you’d like all your colleagues to read your important memo about a new policy governing billing pizza deliveries to the company credit card. You could create a text file and cat it to the wall command:

cat pizza.txt | wall

With this, who needs Facebook?  So you’ve learned about the various run levels and about how they can be invoked from the command line. But how are they defined? As you’ve just seen, you control the way your computer will operate by setting its run level. But, as I hinted earlier, there’s more than one way to do that.  Years ago, run levels were controlled by a daemon (that is, a background process) called init (also known as SysVinit). A computer’s default run level was stored in a text file called inittab that lived in the /etc directory. The critical line in inittab might have looked like this:

id:3:   initdefault

However, these days, if you go looking for the inittab file on your computer, the odds are that you won’t find it. That’s because, as computers with far greater resources became available, and as the demands of multitasking environments increased, more efficient ways of managing complex combinations of processes were needed. Back in 2006, the Upstart process manager was introduced for Ubuntu Linux and was later adopted by a number of other distributions, including Google’s Chrome OS.  Under Upstart, the behavior of the computer under specific run levels is defined by files kept in directories under /etc with names like rc0.d, rc1.d, and rc2.d. The default run level in Upstart is set in the /etc/init/rc- sysinit.conf file. Its critical entry would use this syntax:


Configuration files representing individual programs that are meant to load automatically under specified conditions are similarly kept in the /etc/init/ directory. Here’s part of the ssh.conf file defining the startup and shutdown behavior of the  Secure Shell network connectivity tool  :

start on runlevel [2345] stop on runlevel [!2345] respawn
respawn limit 10 5
umask 022

Leave a Reply

Your email address will not be published.

Previous Post

How to Create Tables in Microsoft Power BI Using DAX Function

Next Post

How to Install XAMPP on Ubuntu using Terminal

Related Posts