Karsten> S is single user. Same as '1'. itz> This is not quite right. itz> itz> S is the real single-user level. 1 OTOH is used just as a itz> way-station
Ethan> not quite, S is for script that need to be run once per boot. Ethan> its run on boot regardless of what runlevel will be entered. Ethan> things like reading the hardware clock, mounting filesystems Ethan> and such need not be done on runlevel changes (even multi -> Ethan> single and back). itz:~$ ls /etc/rc1.d/ K01wdm K19bind K20ippl K20mysql K20xfs-xtt K90sysklogd K01xdm K20apache K20logoutd K20queue K21autofs S20single K11cron K20exim K20lpd K20snort K25ipfw.sh K12kerneld K20gpm K20makedev K20ssh K83chrony K14ppp K20inetd K20modclean K20swapd.sh K89atd itz:~$ cat /etc/rc1.d/S20single #! /bin/sh # # single executed by init(8) upon entering runlevel 1 (single). # # Version: @(#)single 1.10 22-Jun-1998 [EMAIL PROTECTED] # PATH="/sbin:/bin:/usr/sbin:/usr/bin" # Kill all processes. echo -n "Sending all processes the TERM signal... " killall5 -15 echo "done." sleep 5 echo -n "Sending all processes the KILL signal... " killall5 -9 echo "done." # We start update here, since we just killed it. update echo "Entering single-user mode..." exec init -t1 S itz:~$ itz> from multiuser to kill all the multiuser services before entering itz> S with clean slate. If you say "init S" in multiuser you will itz> end up with a root password prompt because all the getties will itz> be killed (being under direct control of init), but the services itz> will stay up. Ethan> init S == init 1 This is in contradiction to what you say above, apart from also being factually wrong: itz:~$ cat /etc/inittab # /etc/inittab: init(8) configuration. # $Id: inittab,v 1.8 1998/05/10 10:37:50 miquels Exp $ # The default runlevel. id:2:initdefault: # Boot-time system configuration/initialization script. # This is run first except when booting in emergency (-b) mode. si::sysinit:/etc/init.d/rcS # What to do in single-user mode. >> ~~:S:wait:/sbin/sulogin << # /etc/init.d executes the S and K scripts upon change # of runlevel. # # Runlevel 0 is halt. # Runlevel 1 is single-user. # Runlevels 2-5 are multi-user. # Runlevel 6 is reboot. l0:0:wait:/etc/init.d/rc 0 >> l1:1:wait:/etc/init.d/rc 1 << l2:2:wait:/etc/init.d/rc 2 l3:3:wait:/etc/init.d/rc 3 l4:4:wait:/etc/init.d/rc 4 l5:5:wait:/etc/init.d/rc 5 l6:6:wait:/etc/init.d/rc 6 # Normally not reached, but fallthrough in case of emergency. z6:6:respawn:/sbin/sulogin # What to do when CTRL-ALT-DEL is pressed. ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now # Action on special keypress (ALT-UpArrow). kb::kbrequest:/bin/echo "Keyboard Request--edit /etc/inittab to let this work." # What to do when the power fails/returns. pf::powerwait:/etc/init.d/powerfail start pn::powerfailnow:/etc/init.d/powerfail now po::powerokwait:/etc/init.d/powerfail stop # /sbin/getty invocations for the runlevels. # # The "id" field MUST be the same as the last # characters of the device (after "tty"). # # Format: # <id>:<runlevels>:<action>:<process> #1:2345:respawn:/sbin/getty 38400 tty1 2:2345:respawn:/sbin/mingetty tty2 3:2345:respawn:/sbin/mingetty tty3 4:2345:respawn:/sbin/mingetty tty4 5:2345:respawn:/sbin/mingetty tty5 6:2345:respawn:/sbin/mingetty tty6 #8:2345:respawn:/usr/local/sbin/toproot # Example how to put a getty on a serial line (for a terminal) # #T0:23:respawn:/sbin/getty -L ttyS0 9600 vt100 #T1:23:respawn:/sbin/getty -L ttyS1 9600 vt100 # Example how to put a getty on a modem line. # #T3:23:respawn:/sbin/mgetty -x0 -s 57600 ttyS3 itz:~$ itz> If you look at /etc/init.d/rcS (the script that init executes itz> when entering S) you'll see that _all_ the sub-scripts in itz> /etc/rcS.d/ are run with "start" as a parameter - which means rcS itz> _never_ kills anything. If you do "init 1" /etc/init.d/rc is run itz> instead, which knows how to kill the services by calling itz> sub-scripts with a "stop" parameter. The last sub-script then itz> does "init S". itz> itz> I don't know why it is done this way; it looks like an ugly hack itz> to me. I'd just have rcS work the same way as rc (indeed they itz> should be the same script). Ask me when I am a developer :) Ethan> its done this way so that its simple to add something to the Ethan> `must be run at boot once' list of things to do. without it Ethan> you would have to edit the main initscript /etc/init.d/rc. Ethan> (which a debian package can't do without violating policy.) Ethan> the rcS.d is basically the equivilent of redhat's rc.local. Ethan> redhat has all the `once at boot' stuff crammed into a much Ethan> more bloated /etc/rc script, which runs rc.local for anything Ethan> packages or the admin needs added. very messy. rcS.d is far Ethan> cleaner and simpler. You didn't get my meaning. I don't object to there being a small rcS script which run-parts a directory; I object to there being rc _and_ rcS which do the same thing, but are distinct. -- Ian Zimmerman, Oakland, California, U.S.A. EngSoc adopts market economy: cheap is wasteful, efficient is expensive.
