Just beforehand: I think this is becoming quite off-topic for this specific bug report, but I have no idea where to redirect it to. If you have, please do, I'll try to follow (except you redirect it to some Wiki where I would need to create an account for :)).
On Mon, Aug 02, 2010 at 04:08:55PM +0200, Petter Reinholdtsen wrote: > [Mario 'BitKoenig' Holbe] > > The functional reason for something belonging to runlevel S is > > hardware setup and configuration, and initial system setup. This is > These are not really the reasons to putting stuff in rcS.d (which is > not the same as runlevel S). Yes, of course - my fault not to express it clearly. Just do as if I had said "for something to run before a runlevel is considered as 'reached' which is managed by putting it into the corresponding rcX.d directory". > Scripts should be put in rcS.d/ if they > have to run before the machine enter runlevel S at boot. runlevel S > is the runlevel running only one process, /sbin/sulogin. rcS.d/ is Uh, should I now go nitpicking as well and ask if runlevel S is considered left once I typed the root password and the only running process is /bin/sh now? :) A while ago it was quite common just to drop into a root-shell once runlevel S was reached. Seriously... runlevel S is a state of the system where only one user (usually root) can access it. Different systems specify it different: some say "where no network is up yet", others say "where no service is running" - they basically all mean the same: fully initialized system, no user-access. > more accurately called rc.boot in other distributions, and they often > require all hooks to go into the real runlevels (0-6). Well, rc.boot comes from BSD boot mimics while we are talking about SysV boot mimics, please try not to mix it up just because others do it. The existence of rc.boot in a SysV style boot usually just marks the historical fact that ancestors of this system had BSD boot mimics. > Most of hardware setup and configuration and initial system setup can > be and should be placed in runlevels 2-6 to ensure that runlevel 1 and > single user become more useful when needing to recover a problematic > machine. You mean, when everybody is booting in "emergency" mode anyways rather than in "single"? :) (some also may prefer init=/bin/dash, of course). Without knowing what your opinion of "problematic" is: as soon as the problems have something to do with filesystem maintenance, "single" is wrong anyways, since runlevel S has rw-mounted filesystems :) Thus, even for such high level problems I clearly prefer "emergency", and of course this applies lower level issues even more :) I personally always thought the single user mode as what it's called: a mode of the machine where no other user is able to access it than a single one - root. Of course, this implies that no or just a few daemons run, because most of them provide services to users, i.e. make users able to access the machine. Of course, single user mode is a maintenance mode - but not for maintenance of hardware or system, but for maintenance of services. > Do not have time to for now. :) You started it under low time, don't blame anybody else for that :) Mario -- () Ascii Ribbon Campaign /\ Support plain text e-mail
signature.asc
Description: Digital signature
