An Introduction To Run-Levels

An introduction to run-IeveIs
Posted by tsstahl on lr| 12 Aug 2005 at 14.26

Tags. initscrits
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:
* 0 Sys1em ha1
* 1 S1hge useJ
* 2 Fu mu11-useJ mode {0e1au1)
* 3-5 Same as 2
* 6 Sys1em Reboo1
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 system always
transitions from one runlevel to another in response to certain conditions.
Special Run Levels
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.
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 1h11 command ("mah 1h11") for more information, but
you can safely skip this for all practical purposes.
An IntroductIon to run-IeveIs http.//www.debIan-admInIstratIon.org/artIcIes/212
1 oI 17 01/17/2014 01.32 IM
Where Does a Run Level Live?
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 /e1c directory according to the following table:
/e1c/Jc0.d Ruh eve 0
Notice a pattern? Each defined runlevel should have an JcX.d directory where X is the run level
number. The contents of the JcX.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:
S10syskogd S20cupsys S20ma1mah S20useJm1h S91apache S99xdm
S11kogd S20ex1m4 S20makedev S20x1s S91apache2
S14ppp S201am S20pcmc1a S20xpJ1h1 S99gdm
S18poJ1map S20hya1ax S20samba S89a1d S99Jmhoog1h
S20acp1d S201he1d S20ssh S89cJoh S99s1op-boo1ogd
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 /e1c/1h11.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 upda1e-Jc.d script)
In slightly modified man page format, here is how the files are named:
|K ] S] + hh + |s1J1hg]
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
2 oI 17 01/17/2014 01.32 IM
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:
S20ex1m4 -> ../1h11.d/ex1m4
S201am -> ../1h11.d/1am
S20hya1ax -> ../1h11.d/hya1ax
S201he1d -> ../1h11.d/1he1d
S20ma1mah -> ../1h11.d/ma1mah
S20makedev -> ../1h11.d/makedev
S20pcmc1a -> ../1h11.d/pcmc1a
S20samba -> ../1h11.d/samba
S20ssh -> ../1h11.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 /e1c/1h11.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:
Jc2.d:
K01xdm S18poJ1map S201am S20makedev S20useJm1h S89cJoh S99Jmhoog1h
S10syskogd S20acp1d S20hya1ax S20pcmc1a S20x1s S91apache S99s1op-boo1og
S11kogd S20cupsys S201he1d S20samba S20xpJ1h1 S91apache2 S99xdm
S14ppp S20ex1m4 S20ma1mah S20ssh S89a1d S99gdm
Jc3.d:
K01gdm S20acp1d S201he1d S20ssh S89cJoh S99xdm
S10syskogd S20cupsys S20ma1mah S20useJm1h S91apache
3 oI 17 01/17/2014 01.32 IM
S11kogd S20ex1m4 S20makedev S20x1s S91apache2
S14ppp S201am S20pcmc1a S20xpJ1h1 S99Jmhoog1h
S18poJ1map S20hya1ax S20samba S89a1d S99s1op-boo1ogd
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, Jc2.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 Jc3.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 'Juheve'
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:
usoho./home/useJ1# Juheve
h 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 '1e1h11'. Get it? "Tell Init" to do something; like
this:
1e1h11 3
1e1h11 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 1e1h11 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
4 oI 17 01/17/2014 01.32 IM
The preferred method for a serious runlevel change is 'shu1dowh'. There are easier mnemonics, but
in a running system they all point to the 'shu1dowh' command. You can use the 'ha1', or
'poweJo11' command to stop a system and the 'Jeboo1' command to restart your system. In each
case they call the 'shu1dowh' 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:
/sb1h/shu1dowh |-1 sec] |-aJkhhc1FhP] 11me |waJh1hg-message]
The vast majority of your shutdowns will follow one of these two forms:
shu1dowh -h how
or to reboot instead of halt:
shu1dowh -J how
Intuitively, the arguments mean 'ha1' and 'Jeboo1', 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 'how' is synonymous with '+0'. Here are two
examples using the time parameter:
shu1dowh -h 16.30
shu1dowh -J +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.
5 oI 17 01/17/2014 01.32 IM
Just to clarify, if Im building a media box with the only feature to bring up freevo (and X11), should I mess
with runlevels, and set it to 1 upon boot? Or is it meaningless
Re: An introduction to run-levels
Posted by Anonymous (200.158.xx.xx) on Sun 6 Nov 2005 at 10:33
The text didn't talk about the most important thing about Debian runlevels, for me, that is HOW DO 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 console boot, but it do not mention how to do it in Debian. As far as I
know, just Debian has this different runlevel configuration, so the most important think in a runlevel text, for
debian, is to tell people how to configure the runlevels in Debian like we could configure it in other linuxs...
It's really a pitty, 'coz it didn't help me. Not even the debian page talk about it. SO, now I don't know how I'll
be able to install my nvidia driver. The X window cannot load to do the nvidia instalation. That's it. Hope
someone put it here to make this text really useful to people, because pretty much all that it has now
(important stuff) is found in the debian page. Not really anything new.
Posted by Anonymous (84.144.xx.xx) on Mon 7 Nov 2005 at 10:27
It seems like we share our 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?
Posted by Anonymous (203.132.xx.xx) on Wed 9 Nov 2005 at 21:23
First of all, you want to find out what is starting X11 on your system. Most likely it's a display manager like
xdm, kdm or gdm. When you first boot up, look at the welcome screen and you should be able to tell if its
kdm (KDE), gdm (Gnome), or xdm (X11).
To make sure you chose the correct display manager, run this command:
ca1 /e1c/X11/de1au1-d1spay-mahageJ
Mine says "/usr/bin/kdm". Yours could be different. (You can edit /etc/X11/default-display-manager to
change the display manager if you want to.)
So run commands like this:
s -a /e1c/Jc*d/*kdm*
s -a /e1c/Jc*d/*gdm*
s -a /e1c/Jc*d/*xdm*
That will produce results something like this. I'm looking at kdm here, because that's the one I'm using.
7 oI 17 01/17/2014 01.32 IM
JwxJwxJwx 1 Joo1 Joo1 13 Feb 14 2005 /e1c/Jc0.d/K01kdm -> ../1h11.d/kdm
JwxJwxJwx 1 Joo1 Joo1 13 Feb 14 2005 /e1c/Jc2.d/S99kdm -> ../1h11.d/kdm
Now 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 only in your system, you should be able to simply change the link for
runlevel 3 for your display manager from start (S) to kill (K). So for example you could try this:
mv /e1c/Jc3.d/S99kdm /e1c/Jc3.d/K01kdm
Then use the telinit command to change to runlevel 3:
1e1h11 3
If you wanted runlevel 3 to be the default, then you need to edit /etc/inittab.
# The de1au1 Juheve.
1d.2.1h11de1au1.
You'd change the '2' to a '3'. Next time you reboot, your system will start in runlevel 3. There will be no
display manager running in runlevel 3, because you turned it off. Therefore, runlevel 3 will become text
only, and it will be the default. If that's what you want to do.
Posted by Anonymous (61.95.xx.xx) on Fri 23 Dec 2005 at 11:41
I tried this in my system. That is I renamed S99gdm as K01gdm (gdm in my case). When I rebooted it,
GNOME login did not open as expected. But even the console login prompt did not come. It was simply
blank. I went back in the recovery mode and fixed it back as S99gdm. Now, how can I get that console
login prompt? Do I need to include some other shell script in that directory?
Posted by Anonymous (132.174.xx.xx) on Mon 13 Feb 2006 at 16:12
sounds like you're trying to do what I am doing on my Kubuntu system. I want the runlevels to work sort of
like RedHat, although in general I like Debian better. I want this:
1 - single user, Kubuntu defaults
2 - single user with sshd so I can remote admin
3 - console only multiuser like RedHat (not that I'd use this on my laptop much, but I like having this option
in general for UNIX operating systems
4 - unused, just going to leave it Kubuntu defaults like Kubuntu rc2.d or my rc5.d
5 - multiuser with X Windows and KDE, the Kubuntu defaults
8 oI 17 01/17/2014 01.32 IM
First I edited /etc/inittab and changed the default runlevel to 5 for my laptop
Then cp -l /etc/rc1.d/ /etc/rc2.d/ and 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 not
work because I'm just hacking around, but if not I'll figure out which one is the text logon that would be
used if you switched this in the system properties with wahtever K tool does this (I know I've been there
before).
Really, you have to expect this to be difficult when you're making runlevels work different on your system.
This is not easy. I did this once on a RedHat system just to screw around and it worked great though. I
can't remember what I was doing but it was probably making use of runlevel 4 on that system.
I also like a previous poster's suggestion to mv things to change S##service to K##service; it's a lot faster
than what I'm doing for most things you'd want to change. Bottom line, know this:
The K scripts in order kill things. The S scripts in order start things. Know what you're killing. Know what
you're starting. And leave yourself a couple untouched run levels in case you screw something up; I
haven't changed single user, 4 or 5, so I can telinit 5 if everything is wrong and I can always start over by
copying rc5.d to another run level. Don't mess with single user and leave one other unchanged, adn
experiment.
as soon as Adept finishes upgrading packages I'm going to try this out. i'll post results.
Posted by Anonymous (65.241.xx.xx) on Wed 15 Feb 2006 at 01:04
Actually the example cited is exactly that: disabling the window manager in runlevel 2.
Re: An introduction to run-levels (Debian Booting in text!!)
Posted by Anonymous (161.109.xx.xx) on Tue 28 Mar 2006 at 19:15
This worked for me. Go to /etc/rc3.d/ there you should find your gui log in mine was gnome so it was
S99gdm. For testing purposes move S99gdm to a temp file somewhere like your home dir. Change your
inittab located (/etc/inittab) to read something like this
# The default runlevel.
id:3:initdefault:
write it the save, restart. This worked for me should you to I am running Debian 3.1_r1 i386. However if
this fails to work during boot it will ask for the root password for you to fix all you have to do is move
S99gdm (in my case) back to the rc3.d folder. I have tried this on the first run level (1) and it didnt work but
the third runlevel works. Good luck!
Posted by Anonymous (132.174.xx.xx) on Tue 14 Feb 2006 at 15:43
9 oI 17 01/17/2014 01.32 IM
well here i am the overachiever. here's what I did:
First, I got rid of something stupid i did, I had 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 to 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
administration 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/username when the /home partition is
unmounted and then just mount over that temporary home dir for normal use, easy workaround)
3 - multiuser, just like Red Hat
4 - multiuser and X on VNC for remote control when 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.)
I changed a line in /etc/inittab to change the default run level to 5.
I created /etc/init.d/vncserver to start and stop 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 vncserver 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 . . . "
10 oI 17 01/17/2014 01.32 IM
start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON || log_end_msg 1
log_end_msg 0
;;
stop)
log_begin_msg "Stopping vncserver daemon . . . "
start-stop-daemon --stop --quiet --oknodo --pidfile $PIDFILE || log_end_msg 1
log_end_msg 0
;;
restart)
log_begin_msg "Restarting vncserver daemon . . . "
start-stop-daemon --stop --quiet --oknodo --retry 30 --pidfile $PIDFILE
start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON || log_end_msg 1
log_end_msg 0
;;
*)
log_success_msg "Usage: /etc/init.d/vncserver {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 /etc/rc1.d/K01vncserver
root@hostname:~# ls /etc/rc4.d
S05vbesave S14ppp S20makedev S21kdm S89cron S99stop-bootlogd
S10acpid S19cupsys S20pcmcia S25bluez-utils S98usplash
S10sysklogd S19hplip S20powernowd S25mdadm S99acpi-support
S11klogd S20apmd S20rsync S89anacron S99fetchmail
S12dbus S20hotkey-setup S20ssh S89atd S99rmnologin
root@hostname:~# ln -s /etc/init.d/vncserver /etc/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
11 oI 17 01/17/2014 01.32 IM
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 K11cron K19hplip K20makedev K20ssh K86ppp S20single
K01usplash K12dbus K20acpi-support K20pcmcia K21acpid K89atd
K01vncserver K15fetchmail K20apmd K20powernowd K25mdadm K89klogd
K11anacron K19cupsys K20hotkey-setup K20rsync K74bluez-utils K90sysklogd
/etc/rc2.d:
K01kdm K12dbus K20apmd K21acpid K89klogd S99stop-bootlogd
K01usplash K15fetchmail K20hotkey-setup K25mdadm K90sysklogd
K01vncserver K19cupsys K20pcmcia K74bluez-utils S15ssh
K11anacron K19hplip K20powernowd K86ppp S20makedev
K11cron K20acpi-support K20rsync K89atd S99rmnologin
/etc/rc3.d:
K01kdm S11klogd S20apmd S20rsync S89atd S99rmnologin
K01vncserver S12dbus S20hotkey-setup S20ssh S89cron S99stop-bootlogd
S05vbesave S14ppp S20makedev S25bluez-utils S98usplash
S10acpid S19cupsys S20pcmcia S25mdadm S99acpi-support
S10sysklogd S19hplip S20powernowd S89anacron S99fetchmail
/etc/rc4.d:
S05vbesave S14ppp S20makedev S21kdm S89atd S99rmnologin
S10acpid S19cupsys S20pcmcia S23vncserver S89cron S99stop-bootlogd
S10sysklogd S19hplip S20powernowd S25bluez-utils S98usplash
S11klogd S20apmd S20rsync S25mdadm S99acpi-support
S12dbus S20hotkey-setup S20ssh S89anacron S99fetchmail
/etc/rc5.d:
K01vncserver S12dbus S20hotkey-setup S20ssh S89atd S99rmnologin
S05vbesave S14ppp S20makedev S21kdm S89cron S99stop-bootlogd
S10acpid S19cupsys S20pcmcia S25bluez-utils S98usplash
S10sysklogd S19hplip S20powernowd S25mdadm S99acpi-support
S11klogd S20apmd S20rsync S89anacron S99fetchmail
12 oI 17 01/17/2014 01.32 IM
IMPORTANT NOTE: change these runlevels at your own 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 left 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 when I was making edits. Now I'm in runlevel 2.
root@hostname:~# ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.0 1560 536 ? S 09:59 0:01 init [2]
--SNIP--
root 6689 0.0 0.1 3540 1540 ? Ss 10:00 0:00 /usr/sbin/sshd
root 7040 0.0 0.0 0 0 ? S< 10:00 0:00 [krfcommd]
root 7134 0.0 0.0 1560 496 tty1 Ss+ 10:00 0:00 /sbin/getty 38400 tty1
root 7208 0.0 0.2 6264 1892 ? Ss 10:02 0:00 sshd: username [priv]
username 7210 0.0 0.2 6264 1988 ? R 10:02 0:00 sshd: username@pts/0
username 7211 0.0 0.2 4672 2080 pts/0 Ss 10:02 0:00 -bash
root 7323 0.0 0.1 3432 972 pts/0 S 10:09 0:00 su -
root 7324 0.0 0.2 2752 1628 pts/0 R 10:09 0:00 -su
root 7986 0.0 0.1 2552 876 pts/0 R+ 10:27 0:00 ps aux
root@hostname:~#
so far so good; the console will allow logins with /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 console
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
13 oI 17 01/17/2014 01.32 IM
start the vncserver never finishes running. the vncserver starts and accepts connections, but obviously I
did something wrong.
root 8540 0.0 0.1 2608 1324 ? Ss 10:30 0:00 /bin/sh /etc/init.d/rc 4
root 8547 0.0 0.0 2588 748 ? Ss 10:30 0:00 /usr/bin/kdm
root 8550 3.1 1.5 13544 11932 ? S 10:30 0:04 /usr/X11R6/bin/X -br -nolisten tc
root 8551 0.0 0.1 2868 1136 ? S 10:30 0:00 -:0
root 8552 0.0 0.1 2644 1328 ? S 10:30 0:00 /bin/sh /etc/rc4.d/S23vncserver s
root 8564 0.0 0.3 4252 2540 ? S 10:30 0:00 /usr/bin/perl /usr/bin/vncserver
root 8568 0.0 0.2 3832 2136 ? S 10:30 0:00 /usr/bin/perl /usr/bin/vncpasswd
root 8569 0.0 0.0 1544 360 ? S 10:30 0:00 /usr/bin/realvncpasswd.real //.vn
root 8572 2.0 2.2 27716 17800 ? S 10:30 0:02 /usr/bin/kdm_greet
root 8577 0.0 0.1 2548 876 pts/0 R+ 10:32 0:00 ps aux
This is for another day, but this should be enough 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/dosadi sometime, although that's NOT UNIX!!!!!
Posted by Anonymous (193.92.xx.xx) on Fri 12 May 2006 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 lot of time searching for an easy way to deactivating the
services on startup at the end I was convinced that there is no easy way and I had to do the renaming.
Anyway I found Debian much better than Red Hat (I used fc3 and red hat 9) on my file servers. apt-get
rocks and this pages helped me a lot.
kyr
Posted by Anonymous (84.161.xx.xx) on Sat 10 Jun 2006 at 19:14
> Why isn't there an easy ncurse utility for managing services like red hat's ntsysv?
There is, it is called sysv-rc-conf.
Posted by Anonymous (125.22.xx.xx) on Tue 20 Jun 2006 at 20:33
There is tool called rcconf (which is better,IMPO) see url http://blogs.cyberciti.biz/hm/index.php
/2005/10/27/removing-unwan ted-startup-debian-files-or-services/
14 oI 17 01/17/2014 01.32 IM
Article Feeds in Atom, RSS, & RDF formats
17 oI 17 01/17/2014 01.32 IM

An Introduction To Run-Levels

Uploaded by

Copyright:

Available Formats

An Introduction To Run-Levels

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

An Introduction To Run-Levels

Uploaded by

Copyright:

Available Formats

An introduction to run-IeveIs

Posted by tsstahl on lr| 12 Aug 2005 at 14.26

You might also like