An introduction to run-levels

http://www.debian-administration.org/articles/212

New User? Register here - Existing Users: Username:

Password:

[Advanced Login]

An introduction to run-levels
Contribute
Submit an Article Submit a Poll Simply put, 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:
Po sted by tsst ahl o n Fri 12 A u g 20 05 a t 14 :26

Flattr

Tags: initscripts

Curre nt Poll
Do you plan using Btrfs soon ? Yes No huh ?
* 0 * 1 * 2 * 3-5 * 6 System Halt Single user Full multi-user mode (Default) Same as 2 System Reboot

Re la ted Link s
Adding init.d scripts

When run levels are discussed they are referred to as 'moving into', or 'going into' a certain run level. The inference is that you came from somewhere. With the exception of booting up, a s ystem always transitions from one runlevel to another in response to certain conditions. Special Run Levels

( 33 votes ~ 1 comments 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 arc hitectures 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.

Re cent We blogs
Upg rad e
by a jt

(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. In the interests of completeness, there is also a runlevel 'S' that the system uses on it's way to another runlevel. Read the man page for the init command ("man init") for more information, but you can safely skip this for all practical purposes.

2 comments

Hit bu g 553173 - /jav ascript in apache n amespace Where Does a Run Level Live?
b y sim onw

T he size o f Deb Con f12

b y rk d

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 /etc/rc1.d /etc/rc2.d /etc/rc3.d /etc/rc4.d /etc/rc5.d /etc/rc6.d Run level 0 Run level 1 Run level 2 Run level 3 Run level 4 Run level 5 Run level 6

KVM, Wind ow s XP, and Stop Error Co de 0x0000007B

by dk g

2 comments
Add N ew Weblog En try
by r gopi

Notice a pattern? Each defined runlevel should have an rcX.d directory where X is the run level number. The contents of the rcX.d directory determines what happens at that run level. (S)tart files, (K)ill files 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:

Ango sso
b y A ngoss o

Best d ata recovery?

b y m ar io

2 comments
BASH C olors rev isited
by s ne ex

3 comments
Com puted colors in prom pt
b y m cor te se

S10sysklogd S11klogd S14ppp S18portmap S20acpid

S20cupsys S20exim4 S20fam S20hylafax S20inetd

S20mailman S20makedev S20pcmcia S20samba S20ssh

S20usermin S20xfs S20xprint S89atd S89cron

S 91apache S 91apache2 S 99gdm S 99rmnologin S 99stop-bootlogd

S99xdm

1 comment
zinF ram eDriv er: disagrees abou t version o f symbo l
b y ole xa ndr _k ly m enk o

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]

1 comment Archived weblogs

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 fac t 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: rc2.d:
K01xdm S18portmap S20fam S20makedev S20us ermin S89cron S99rmnologin S10sysklogd S20acpid S20hylafax S20pcmcia S20xf s S91apache S99stop-bootlogd S11klogd S20cupsys S20inetd S20samba S20xp rint S91apache2 S99xdm S14ppp S20exim4 S20mailman S20ssh S89at d S99gdm

rc3.d:
K01gdm S10sysklogd S11klogd S14ppp S18portmap S20acpid S20cupsys S20exim4 S20fam S20hylafax S20inetd S20mailman S20makedev S20pcmcia S20samba S20ssh S20usermin S20xfs S20xprint S89atd S 89cron S 91apache S 91apache2 S 99rmnologin S 99stop-bootlogd S99xdm

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. That's great, but 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 3

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 [warnin g-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. Troubleshooting in Run Levels Here is a tip contributed by Nicholas Petreley. Sometimes you may not want all the programs in a run level to execute. In this situation an easy way to disable a program is to rename it with the initial S, or K in lowercase. The system will ignore all programs that do not begin with a capital S, or K. This article was originally written as part of a course for UserLinux system administration. It initially appeared on the UserLinux wiki here. The wiki version, as a living document, may have more, or less to offer in the way of content. (UserLinux is a subset of Debian. Everywhere 'UserLinux' appears, you can substitute 'Debian' with equal facility.)

Re: An introduction to run-leve ls

Posted b y grimoire (82 .6 9.xx.xx) on M on 15 A ug 20 05 at 14:22 [ Send Mes sage ]

It's worth noting that there's rarely any actual need to mess around w ith runlevels; fro m doing D ebian suppo rt on IRC , I know that 99% o f o ccasio ns where people think they need to play with them, they've got the wro ng end of the stick. Readers may also want to f amiliarise themselves with the in vok e- rc. d and upd ate -rc .d scripts if they are going to manipulate startup scripts.

Re: An introduction to run-leve ls

Posted by Anony mous (1 95.21 2.xx.xx) on M on 15 A ug 20 05 at 14:47

runlevels are usef ul for a co uple of things: correct bo ot order of specific processes, e.g. pcmcia switch to runlevel 1 fo r upgrades modifying X or other import ant infrastructure tools, stopping all non-essential processes to avoid pro blems

Re: An introduction to run-leve ls

Posted b y r edsolo (85 .2 24.xx.xx) o n Tue 20 S ep 20 05 at 21:37 [ Send Mes sage ]

Just to clarif y, if Im building a media bo x with the o nly f eature to bring up f reevo (and X11), sho uld I mess with runlevels, and set it to 1 upon boo t? Or is it meaningless

Re: An introduction to run-leve ls

Po ste d by Anonym ous (20 0.158 .xx.xx) on Sun 6 N ov 20 05 at 10:33

T he text didn't talk about the most impo rtant thing about Debian runlevels, f or me, that is H OW D O I BOOT IN TEXT MODE IN DEBIAN? ?? By the text, runlevels 2-6 are all the same. It mention that runlevel 3 is used in other distributions as a text co nsole boot, but it do not mentio n ho w to do it in D ebian. As far as I know, just Debian has this dif ferent runlevel configuratio n, so the most importa nt think in a runlevel text, f or debian, is to tell people ho w to configure the runlevels in Debian like we co uld co nf igure it in o ther linuxs... It's really a pitty, 'coz it didn't help me. No t even the debian page talk about it. SO, now I do n't know how I'll be able to install my nvidia driver. The X windo w cannot lo ad to do the nvidia instalation. That's it. Ho pe so meone put it here to make this text really useful to people, because pretty much all that it has now (important stuff) is fo und in the debian page. N ot really anything new.

Re: An introduction to run-leve ls

Po ste d by Anonym ous (84 .1 44.xx.xx) o n Mon 7 N ov 20 05 at 10:27

It seems like we share o ur problems... Did I get this right? I only need to edit the rcX.d file (after backing it up) to set up my "own" runlevels und then telinit to the changed level?

Re: An introduction to run-leve ls

Posted by Anony mous ( 203 .1 32.xx.xx) o n Wed 9 N ov 20 05 at 21:23

First of all, you want to find out what is starting X11 on yo ur system. Most likely it's a display manager like xdm, kdm or gdm. When yo u f irst bo ot up, loo k at the welcome screen and you sho uld be able to tell if its kdm (KDE), gdm (Gno me), or xdm (X11). To make sure you chose the correct display manager, run this command: cat /etc/X11/default-display-manager Mine says "/usr/bin/kdm". Yo urs could be diff erent. (You can edit /etc/X11/def ault-display-manager to change the display manager if you want to .) So run commands like this: ls -la /etc/rc*d/*kdm* ls -la /etc/rc*d/*gdm* ls -la /etc/rc*d/*xdm* T hat will produce results something like this. I'm lo oking at kdm here, because that's the one I'm using. lrwxrwxrwx lrwxrwxrwx lrwxrwxrwx lrwxrwxrwx lrwxrwxrwx lrwxrwxrwx lrwxrwxrwx 1 1 1 1 1 1 1 root root root root root root root root root root root root root root 13 13 13 13 13 13 13 Feb Feb Feb Feb Feb Feb Feb 14 14 14 14 14 14 14 2005 2005 2005 2005 2005 2005 2005 /etc/rc0 .d/K01kdm /etc/rc1 .d/K01kdm /etc/rc2 .d/S99kdm /etc/rc3 .d/S99kdm /etc/rc4 .d/S99kdm /etc/rc5 .d/S99kdm /etc/rc6 .d/K01kdm -> -> -> -> -> -> -> ../init.d/kdm ../init.d/kdm ../init.d/kdm ../init.d/kdm ../init.d/kdm ../init.d/kdm ../init.d/kdm

No w what this means is that kdm starts in runlevels 2, 3, 4, and 5. kdm is stopped in runlevels 0, 1, and 6. If you want runlevel 3 to be text o nly in your system, you should be able to simply change the link fo r runlevel 3 f or your display manager fro m start (S) to kill (K). So f or example you could try this: mv /etc/rc3.d/S99kdm /etc/rc3.d/K01kdm T hen use the telinit command to change to runlevel 3: telinit 3 If you wanted runlevel 3 to be the default, then you need to edit /etc/inittab. # The default runlevel. id:2:initdefault: You'd change the '2' to a '3'. Next time you reboo t, yo ur system will start in runlevel 3. There will be no display manager running in runlevel 3, because you turned it o ff. T herefo re, runlevel 3 will become text only, and it will be the default. If that's what yo u want to do .

Re: An introduction to run-leve ls

Po ste d by Anonym ous (6 1.95.xx.xx) o n Fri 23 De c 2 005 a t 11:41

I tried this in my system. T hat is I renamed S99gdm as K01gdm (gdm in my case). When I rebo oted it, GN OM E login did not o pen as exp ected. But even the conso le lo gin pro mpt did not come. It was simply b lank. I went back in the recovery mode and fixed it back as S99gdm. N ow, ho w can I get that conso le lo gin pro mpt? Do I need to include some o ther shell script in that directory?

Re: An introduction to run-leve ls

Posted b y A nonymous (132 .1 74.xx.xx) o n Mon 1 3 Feb 20 06 at 16:12

sounds like you're trying to do what I am do ing on my Kubuntu syste m. I want the runlevels to work sort o f like R edHat, although in general I like Debian better. I want this: 1 - single user, Kubuntu defaults 2 - single user with sshd so I can remo te admin 3 - console o nly multiuser like RedH at (not that I'd use this o n my la ptop much, but I like having this option in general f or U NIX operating systems 4 - unused, just going to leave it Kubuntu defaults like Kubuntu rc2.d o r my rc5.d 5 - multiuser with X Windo ws and KDE, the Kubuntu defaults First I edited /etc/inittab and changed the default runlevel to 5 f or my laptop T hen cp -l /etc/rc1.d/ /etc/rc2.d/ an d cp -l /etc/rc3.d / /etc/rc2.d and then delete all the links I don't want to make everything killed and only start sshd first (S15ssh) and then single user (S20single). This might no t work because I'm just hacking aro und, but if no t I'll figure out which o ne is the text lo gon that wo uld be used if you switched this in the system properties with wahtever K too l does this (I kno w I've been there bef ore). Really, you have to expect this to be dif ficult when yo u're making runlevels work diff erent on yo ur system. T his is not easy. I did this o nce on a R edHat system just to s crew around and it worked great though. I can't remember what I was doing but it was probably making use of runleve l 4 on that system. I also like a previo us poster's suggestion to mv things to change S##service to K##service; it's a lot faster than what I'm doing f or mo st things you'd want to change. Bo ttom line, know this: T he K scripts in order kill things. T he S scripts in order start things. Kno w what you're killing. Kno w what you're starting. And leave yo urself a couple untouched run levels in case you screw so mething up; I haven't changed single user, 4 or 5, so I can telinit 5 if everything is wro ng and I can always start o ver by copying rc5.d to ano ther run level. Don't mess with single user and leave one other unchanged, adn experiment. as so on as Adept f inishes upgrading packages I'm going to try this o ut. i'll post res ults.

Re: An introduction to run-leve ls

Posted b y A nonymous (65 .2 41.xx.xx) o n Wed 1 5 Feb 20 06 at 01:04

Actually the example cited is exactly that: disabling the windo w manager in runlevel 2.

Re: An introduction to run-leve ls (Debia n Booting in text!!)

Posted by Anony mous ( 161 .1 09.xx.xx) o n Tue 28 M ar 20 06 at 19:15

T his worked for me. Go to /etc/rc3.d/ there yo u should find yo ur gui log in mine was gnome so it was S99gdm. For testing purposes mo ve S99gdm to a temp file somewhere lik e yo ur ho me dir. C hange your inittab lo cated (/etc/inittab) to read so mething like this # T he def ault runlevel. id:3:initdefault: write it the save, restart. T his worked for me should you to I am running D ebian 3.1_r1 i386. Ho wever if this fails to work during bo ot it will ask f or the ro ot passwo rd fo r you to fix all you have to do is move S99gdm (in my case) back to the rc3.d f older. I have tried this on the f irst run level (1) and it didnt work but the third runlevel works. Go od luck!

Re: An introduction to run-leve ls

Posted b y A nonymous (13 2.174 .xx.xx) on Tue 1 4 Feb 20 06 at 15:43

well here i am the overachiever. here's what I d id:

First, I got rid of something stupid i did, I ha d put S20single in rc2.d . Duh. Right after S15ssh . So then I read /etc/init.d/single and found out that it kills all other processes to enter single user mode. So don 't do this! ;)

I was remoting my lappy from work, and guess what, telinit 2 ended my experiment until I could get home last night. Got home late, just rebooted, and I' m finishing up this mroning.

So here's the real deal: 1 - single user 2 - I wanted single-user with sshd, but I have t o log in as a user for ssh because I don't like letting the security hole of root logging in directly from remote. So this runlevel is multiuser, barely, for remote adm inistration when I want to unmount everything. (yeah, I'm sshing into a user account so technically I need /home/username mounted . . . . I'll have to create /home/user name when the /home partition is unmounted and then just mount over that temporary home dir 3 - multiuser, just like Red Hat 4 - multiuser and X on VNC for remote control wh en I'm behind my firewall and I want to remote control my laptop from work. I don't really want X running on console, not that it matters. 5 - multiuser with X on console and no VNC for " normal use". (This should not leave stupid security holes like VNC for when I'm in a coffee shop etc.)

1 of 3

7/3/2012 6:00 PM

An introduction to run-levels

http://www.debian-administration.org/articles/212

I changed a line in /etc/inittab to change the d efault run level to 5.

I created /etc/init.d/vncserver to start and sto p this new service, using the scripts already in that directory to model:

root@hostname:~# cat /etc/init.d/vncserver #! /bin/sh # # /etc/init.d/vncserver: Start and stop the vncs erver daemon #

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/ usr/sbin:/usr/bin DAEMON=/usr/bin/vncserver PIDFILE=/var/run/vncserver.pid NAME=vncserver

test -f $DAEMON || exit 0

set -e

. /lib/lsb/init-functions

case "$1" in start) log_begin_msg "Starting vncserver daemon . . . " start-stop-daemon --start --quiet --pidf ile $PIDFILE --exec $DAEMON || log_end_msg 1 log_end_msg 0 ;; stop) log_begin_msg "Stopping vncserver daemon . . . " start-stop-daemon --stop --quiet --oknod o --pidfile $PIDFILE || log_end_msg 1 log_end_msg 0 ;;

restart) log_begin_msg "Restarting vncserver daem on . . . " start-stop-daemon --stop --quiet --oknod o --retry 30 --pidfile $PIDFILE start-stop-daemon --start --quiet --pidf ile $PIDFILE --exec $DAEMON || log_end_msg 1 log_end_msg 0 ;;

*) log_success_msg "Usage: /etc/init.d/vncs erver {start|stop|restart}" exit 1 esac

exit 0 root@hostname:~#

I tested the script by running it like # /etc/init.d/vncserver start # /etc/init.d/vncserver stop and it ran fine, so then to make the links:

root@hostname:~# ln -s /etc/init.d/vncserver /et c/rc1.d/K01vncserver root@hostname:~# ln -s /etc/init.d/vncserver /et c/rc2.d/K01vncserver root@hostname:~# ln -s /etc/init.d/vncserver /et c/rc3.d/K01vncserver root@hostname:~# ln -s /etc/init.d/vncserver /et c/rc5.d/K01vncserver root@hostname:~# ls /etc/rc4.d S05vbesave S10acpid S10sysklogd S11klogd S12dbus S14ppp S19cupsys S19hplip S20apmd S20hotkey-setup S20makedev S20pcmcia S20powernowd S20rsync S20ssh S21k dm S25b luez-utils S25m dadm S89a nacron S89a td S89cron S98usplash S99acpi-support S99fetchmail S99rmnologin S99stop-bootlogd

root@hostname:~# ln -s /etc/init.d/vncserver /et c/rc4.d/S23vncserver

The links run in order, first the kills then the starts, so I decided to put it after kdm. I might decide to get rid of kdm there so I would do this: # mv /etc/rc4.d/S21kdm /etc/rc4.d/K01kdm I'm not sure if that will work or not until I'm sitting in front of the laptop so I can't test this morning. But I can test just about everything except what's going on with the local console from remote. Probably I could test that enough from remote as well if I get creative with various tools and do some logical deduction. But it's easier to sit down tonight ;)

I also changed the rc2.d and rc3.d scripts a bit to accomplish my goal of starting the graphical desktop or not, etc; there's what I've got:

root@hostname:~# ls /etc/rc*.d

/etc/rc1.d: K01kdm K01usplash K01vncserver K11anacron K11cron K12dbus K15fetchmail K19cupsys K19hplip K20acpi-support K20apmd K20hotkey-setup K20 makedev K20 pcmcia K20 powernowd K20 rsync K20ssh K21acpid K25mdadm K74bluez-utils K86ppp K89atd K89klogd K90sysklogd S20single

/etc/rc2.d: K01kdm K01usplash K01vncserver K11anacron K11cron K12dbus K15fetchmail K19cupsys K19hplip K20acpi-support K20apmd K20hotkey-setup K20pcmcia K20powernowd K20rsync K21acpid K25mdadm K74bluez-utils K86ppp K89atd K89klogd K90sysklogd S15ssh S20makedev S99rmnologin S99stop-bootlogd

/etc/rc3.d: K01kdm K01vncserver S05vbesave S10acpid S10sysklogd S11klogd S12dbus S14ppp S19cupsys S19hplip S20apmd S20hotkey-setup S20makedev S20pcmcia S20powernowd S20rsy nc S20ssh S25blu ez-utils S25mda dm S89ana cron S89atd S89cron S98usplash S99acpi-support S99fetchmail S99rmnologin S99stop-bootlogd

/etc/rc4.d: S05vbesave S10acpid S10sysklogd S11klogd S12dbus S14ppp S19cupsys S19hplip S20apmd S20hotkey-setup S20makedev S20pcmcia S20powernowd S20rsync S20ssh S21k dm S23v ncserver S25b luez-utils S25m dadm S89a nacron S89atd S89cron S98usplash S99acpi-support S99fetchmail S99rmnologin S99stop-bootlogd

/etc/rc5.d: K01vncserver S05vbesave S10acpid S10sysklogd S11klogd S12dbus S14ppp S19cupsys S19hplip S20apmd S20hotkey-setup S20makedev S20pcmcia S20powernowd S20rsync S20ssh S21kdm S25blu ez-utils S25mda dm S89ana cron S89atd S89cron S98usplash S99acpi-support S99fetchmail S99rmnologin S99stop-bootlogd

IMPORTANT NOTE: change these runlevels at your o wn peril. Especially DO NOT CHANGE rc0.d rc1.d rcS.d or rc6.d unless you REALLY REALLY know what you're doing, and leave yourself a backup someplace; for instance I lef t rc5.d untouched even after all my heavy modifications, so if I really screw up I can always boot to either level 5 or single user and then copy the rc5.d scripts over whatever runlevel I hopelessly screwed up.

root@hostname:~# telinit 2 root@hostname:~# runlevel 3 2

As you can see I was in runlevel 3 previously wh en I was making edits. Now I'm in runlevel 2.

root@hostname:~# ps aux USER root --SNIP-root root 6689 7040 0.0 0.0 0.1 0.0 3540 0 1540 ? 0 ? Ss S< 10:00 10:00 0:00 /usr/sbin/sshd 0:00 [krfcommd] PID %CPU %MEM 1 0.0 0.0 VSZ 1560 RSS TTY 536 ? S TAT START S 09:59 TIME COMMAND 0:01 init [2]

2 of 3

7/3/2012 6:00 PM

An introduction to run-levels

http://www.debian-administration.org/articles/212

root root username username root root root root root root root root

7134 7208

0.0 0.0

0.0 0.2

1560 6264

496 tty1 1892 ? 1988 ? 2080 pts/0

S s+ Ss R

10:00 10:02

0:00 /sbin/getty 38400 tty1 0:00 sshd: username [priv] 0:00 sshd: username@pts/0 0:00 -bash

7210 7211 7323 7324 7408 7411 7414 7417 7420 7986

0.0 0.0

0.2 0.2

6264 4672

10:02 10:02

Ss S R S s+ S s+ S s+ S s+ S s+ R+

0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0

0.1 0.2 0.0 0.0 0.0 0.0 0.0 0.1

3432 2752 1556 1556 1560 1556 1560 2552

972 pts/0 1628 pts/0 488 tty2 492 tty3 492 tty4 492 tty5 496 tty6 876 pts/0

10:09 10:09 10:26 10:26 10:26 10:26 10:26 10:27

0:00 su 0:00 -su 0:00 /sbin/getty 38400 tty2 0:00 /sbin/getty 38400 tty3 0:00 /sbin/getty 38400 tty4 0:00 /sbin/getty 38400 tty5 0:00 /sbin/getty 38400 tty6 0:00 ps aux

root@hostname:~#

so far so good; the console will allow logins wi th /sbin/getty, X windows is not running, and sshd is still running (or I wouldn't still be connected!)

I do telinit 3 and it starts bluetooth, pcmcia, etc and it's a full system but without X windows; console only just like I wanted. telinit 5 also works just fine and is the default for Kubuntu, x windows runs, the co nsole takes logons, sshd runs, and the vnc server doesn't start.

ahem. I seem to have a problem with runlevel 4. It runs, everything goes well, EXCEPT that my rc script to start the vncserver never finishes running. the vncserver starts and accepts connections, but obviously I did something wrong.

root root root root root root root root root root

8540 8547 8550 8551 8552 8564 8568 8569 8572 8577

0.0 0.0 3.1 0.0 0.0 0.0 0.0 0.0 2.0 0.0

0.1 0.0 1.5 0.1 0.1 0.3 0.2 0.0 2.2 0.1

2608 2588

1324 ? 748 ?

Ss Ss S S S S S S S R+

10:30 10:30 10:30 10:30 10:30 10:30 10:30 10:30 10:30 10:32

0:00 /bin/sh /etc/init.d/rc 4 0:00 /usr/bin/kdm 0:04 /usr/X11R6/bin/X -br -nolisten tc 0:00 -:0 0:00 /bin/sh /etc/rc4.d/S23vncserver s 0:00 /usr/bin/perl /usr/bin/vncserver 0:00 /usr/bin/perl /usr/bin/vncpasswd 0:00 /usr/bin/realvncpasswd.real //.vn 0:02 /usr/bin/kdm_greet 0:00 ps aux

13544 11932 ? 2868 2644 4252 3832 1544 1136 ? 1328 ? 2540 ? 2136 ? 360 ?

27716 17800 ? 2548 876 pts/0

This is for another day, but this should be enou gh to tell people on thsi forum how to use runlevels. Just be careful! And keep backups! UNIX is beautiful once you get under the hood a little bit. Learn UNIX and any linux or BSD operating system is rediculously easy, far easier than spelling rideculously correctly ;)

if you are curious drop by www_urnotalone_com/do sadi sometime, although that's NOT UNIX!!!!!

Re: An introduction to run-leve ls

Posted by Anony mous (1 93.92 .xx.xx) on Fri 12 M ay 20 06 at 02:10

Why isn't there an easy ncurse utility for managing services like red hat's ntsysv? I've switched over debian resently and I spent a lo t of time searching fo r an easy way to deactivating the services on startup at the end I was co nvinced that there is no easy way and I had to do the renaming. Anyway I fo und Debian much better than R ed Hat (I used fc3 and red hat 9) on my file servers. apt-get ro cks and this pages helped me a lo t. kyr

Re: An introduction to run-leve ls

Posted b y A nonymous (84.16 1.xx.xx) on Sa t 10 J un 20 06 at 19:14

> Why isn't there an easy ncurse utility fo r managing services like re d hat's ntsysv? T here is, it is called sysv-rc-co nf .

Re: An introduction to run-leve ls

Posted b y A nonymous (12 5.22.xx.xx) o n Tue 20 J un 20 06 at 20:33

T here is too l called rcconf (which is better,IMPO) see url http://blogs.cyberciti.biz/ hm/ind ex.php /2005/10/27/rem oving -un wan ted-startup-debian- files -or-services/

Roll it yourse lf?

Posted by Anony mous (1 92.94 .xx.xx) on Thu 21 M ay 20 09 at 02:48

It's funny that the author mentions the fact that other Linuxes use runlevel to start and sto p X11 - but fails to explain the D ebian appro ach. Debian users have to tailor their own non-gui mode?!? Seems like an uncessary pain.

A rti cle s an d co mm en ts a re the p ro p erty of the ir res pe ctive po ste rs. Trad e marks a re the pro p erty of the ir res pe ctive ow ne rs. D eb ia n is a r e gis te re d tra de ma r k o f Softwa re in the P ublic Inte re s t, Inc. This s ite is c op yrig ht 2 00 4 -20 11 Ste ve Ke m p. Si te ho sting pro vid e d b y B y tem a rk Hos ting. Ar ticle Fe e ds in A tom , RS S, & RD F for m ats

3 of 3

7/3/2012 6:00 PM