A 'runlevel' determines which programs are executed at system startup. Most of your exposure to run levels will deal with system startup. You will become intimately familiar with the exceptions the first time you have to troubleshoot a failed system.Linux run levels are numbered 0 through 6. Run levels stop at six for practical and historical reasons, but it is entirely possible to have more if desired.
The following table summarises the UserLinux run levels:
* 0 System Halt * 1 Single user * 2 Full multi-user mode (Default) * 3-5 Same as 2 * 6 System Reboot
- Run level 0 is the system halt condition. Nearly all modern X86 computers will power off automatically when run level 0 is reached. Older X86 computers, and various different architectures will remain powered on and display a message referring to the halt condition.
- Run Level 1 is known as 'single user' mode. A more apt description would be 'rescue', or 'trouble-shooting' mode. In run level 1, no daemons (services) are started. Hopefully single user mode will allow you to fix whatever made the transition to rescue mode necessary. (You can boot into single user mode typically by using your boot loader, lilo or grub, to add the word 'single' to the end of the kernel command line).
- Run levels 2 through 5 are full multi-user mode and are the same in a default UserLinux (Debian) system. It is a common practise in other Linux distributions to use run level 3 for a text console login and run level 5 for a graphical login.
- Run level 6 is used to signal system reboot. This is just like run level 0 except a reboot is issued at the end of the sequence instead of a power off.
Like everything else in a Linux system, run levels are defined by files in the filesystem. All the run level files are found in the /etc directory according to the following table:
/etc/rc0.d Run level 0 /etc/rc1.d Run level 1 /etc/rc2.d Run level 2 /etc/rc3.d Run level 3 /etc/rc4.d Run level 4 /etc/rc5.d Run level 5 /etc/rc6.d Run level 6
Let's look at run level 2 since this is where we'll spend most of our time.
Here are the contents of a generic rc2.d directory:
S10sysklogd S20cupsys S20mailman S20usermin S91apache S99xdm S11klogd S20exim4 S20makedev S20xfs S91apache2 S14ppp S20fam S20pcmcia S20xprint S99gdm S18portmap S20hylafax S20samba S89atd S99rmnologin S20acpid S20inetd S20ssh S89cron S99stop-bootlogd
At first glance the files in this directory look kind of intimidating. They should be. The files in the rcX.d directories are formatted for the computer to read, not the user.
Each file is a symbolic link to a script residing in the /etc/init.d directory and controls the starting, or stopping of a program, or daemon (service).
This is important enough to say again, each file is a symbolic link to a script and controls the starting, or stopping of a program, or daemon.
(If you wish to add your own startup script you can do so via the update-rc.d script)
In slightly modified man page format, here is how the files are named:
[K | S] + nn + [string]
Working backwards, here is how the name parses out. The [string] is a human readable mnemonic for the executable file that is actually symbolically linked to. The 'nn' is a two digit number from 01-99; lower number programs are executed first. By this method, services that have a dependancy can be certain their precursor has ran. The K and S signify simply Kill, or Start.
When a system moves into a new runlevel, all the files that begin with S will be executed. When a system moves into a new runlevel all the files that begin with K will be executed. Yes, all the files will execute, but with one distinct difference: 'S' files invoke their program with the 'start' parameter, the 'K' files invoke their program with the 'stop' parameter. The UserLinux (Debian) system optimizes the runlevel change by not starting a daemon that is already running.
The simple elegance of this system is made possible by the alphabet. All the scripts will execute in alphabetical order. 'K' comes before 'S', so programs are stopped before they are started. Forgetting this fact can lead to a lot of chin scratching while manipulating your rcX.d files.
After the first letter comes the integer, again determining execution order. Finally, the mnemonic portion is followed alphabetically to determine execution order.
Let's look at some of the programs that are actually executed during a run level change:
S20exim4 -> ../init.d/exim4 S20fam -> ../init.d/fam S20hylafax -> ../init.d/hylafax S20inetd -> ../init.d/inetd S20mailman -> ../init.d/mailman S20makedev -> ../init.d/makedev S20pcmcia -> ../init.d/pcmcia S20samba -> ../init.d/samba S20ssh -> ../init.d/ssh
All of these files have the same precedence as far as the system is concerned. They will be executed in the order listed, i.e. alphabetically.
All of the scripts that run during system start-up actually reside in the /etc/init.d/ directory, as suggested by the listing. The reasons for this are many, but basically boil down to common sense issues like: saving space, single point for editing, and everyone knowing where to find things.
Transitioning Between Run levels
When you leave a runlevel, nothing happens. All the action takes place when you enter the new run level.
Look at the following two rcX.d listings:
K01xdm S18portmap S20fam S20makedev S20usermin S89cron S99rmnologin S10sysklogd S20acpid S20hylafax S20pcmcia S20xfs S91apache S99stop-bootlogd S11klogd S20cupsys S20inetd S20samba S20xprint S91apache2 S99xdm S14ppp S20exim4 S20mailman S20ssh S89atd S99gdm
K01gdm S20acpid S20inetd S20ssh S89cron S99xdm S10sysklogd S20cupsys S20mailman S20usermin S91apache S11klogd S20exim4 S20makedev S20xfs S91apache2 S14ppp S20fam S20pcmcia S20xprint S99rmnologin S18portmap S20hylafax S20samba S89atd S99stop-bootlogd
Look intensely at the two listings while allowing your eyes to unfocus. An image of a gnu will eventually appear. Ok, no it won't, but you believed for just a second, didn't you?
Look at the first listing, rc2.d. Notice the contradiction between the first program and the last program. K01xdm instructs the system to Kill xdm upon entering run level 2; S99xdm tells the system to start xdm. Who wins? Both programs are executed, but the last program to run will prevail. S99xdm, as it appears last in the alphabetical sequence, will leave xdm in a running state. The change to runlevel 2 was wasted typing.
Now, let's look closely at the rc3.d listing. The first thing that will be executed is the stopping of gdm, which is the default graphical display manager for UserLinux (Debian). Note the S99gdm file (symlink) has been removed. The purpose of the change is to move to a runlevel where everything else is still running, except the pretty window manager. This situation is called 'console mode'. As mentioned previously, many Linux distributions use run level 3 for console mode.
How do I change run levels?
Before we change run levels it might help to find out which run level is current. Use the 'runlevel' command to tell you two things: The last run level, and the current run level. Here is the command and the output shown together due to the sparsity of the output:
ulsoho:/home/user1# runlevel N 2
The 'N' stands for none, meaning there has been no run level change since powering up.
The init system controls run levels, but then again, the init system pretty much controls everything. The init system will be looked at in detail in a future article.
The primary command used to change run levels is 'telinit'. Get it? "Tell Init" to do something; like this:
telinit takes one argument on the command line. As always, see the man page for full details. Normally the argument will be one of: 0,1,2,3,4,5,6, or the letter 'S'. As you may have guessed, the numbers correspond to the run level you wish to move to. Using the 'S', for single-user, is the same as the number 1, but don't do it; the 'S' runlevel is intended for use by the UserLinux (Debian)system.
A note of caution is warranted here. You can easily use the telinit command to reboot (run level 6), or shutdown (run level 0) the system, but it is not recommended. Certain programs need special processing for an orderly shutdown. Bypassing the expected shutdown sequence can have dire effects on your data. Older _Unix_ systems are especially sensitive to shutdown/bootup operations
The preferred method for a serious runlevel change is 'shutdown'. There are easier mnemonics, but in a running system they all point to the 'shutdown' command. You can use the 'halt', or 'poweroff' command to stop a system and the 'reboot' command to restart your system. In each case they call the 'shutdown' command with different parameters.
(We've covered shutting down your Debian machine previously)
In a single system (non-networked, or no locally shared resources) environment, the shutdown choice is pretty much yours. However, in a multi-user production system the rule of thumb is learn the shutdown command. The two most basic uses of the 'shutdown' command are for halting, or rebooting. The important parameter to know for shutdown is WHEN is the action going to occur. Here is the command synopsis from the shutdown man page:
/sbin/shutdown [-t sec] [-arkhncfFHP] time [warning-message]
The vast majority of your shutdowns will follow one of these two forms:
shutdown -h now
or to reboot instead of halt:
shutdown -r now
Intuitively, the arguments mean 'halt' and 'reboot', respectively.
In a multi-user system like a file server, the most important parameter is 'time'. The time can be an actual clock time in the form of HH:MM, or a Julian style shutdown X minutes from now, denoted by the +X syntax. Note that the '+' is needed. The keyword 'now' is synonymous with '+0'. Here are two examples using the time parameter:
shutdown -h 16:30 shutdown -r +10
Another important point to remember: once the shutdown command is issued, a notice is sent to all the users of the system and no further logins are allowed. For example, if you need to bring the system down at midnight, don't issue the shutdown command at noon and leave to take a nap. No new users will be able to login for the next 12 hours.
A good admin never takes a system down without warning the user community, but the shutdown notice is only sent after the command is executed! Fortunately, there are two ways around the downtime notification dilemma. The first is the 'motd', Message Of The Day. The motd is a useful feature that is often overlooked. Using the motd is easy and you are urged to read the simple man page for details. The second method of notification is the -k option. Using -k will send the downtime notice to all the users, but will not actually start the shutdown sequence. There is an important limitation to the shutdown notification: the downtime message is only sent 15 minutes (or less) prior to the actual shutdown.
The warning-message parameter may be useful for...high maintenance users. I find that the default message is authoritative and simple enough to accomplish the task.
Task: Command line tool to manage services / Ubuntu runlevel
update-rc.d automatically updates the System V style init script links /etc/rcrunlevel.d/NNname to scripts /etc/init.d/name. These are run by init when changing runlevels and are generally used to start and stop. For example turn on ssh service type the command:
# update-rc.d ssh defaults
Task: Remove service
Again use update-rc.d command:
# update-rc.d SERVICE-NAME remove
Task: Enable service
Again use update-rc.d command:
# update-rc.d SERVICE-NAME enable
Task: Disable service
Again use update-rc.d command:
# update-rc.d SERVICE-NAME disable