On Wed, 13 Sep 2006, Petter Reinholdtsen wrote: > runlevel 2. The result is that start scripts started with the symlink > in rcS.d/ will also run with the symlink in rc2.d/.
Given that this is allowed behaviour (not rerunning start scripts is an optimization, but just that), I don't know what to think of this bug. > I'm not quite sure why, but suspect the reason is that init expect > runlevel 'S' to be single-user, and not the bootup runlevel. Well, if it is thinking of runlevel 'S' as single-user, it is an *extremely hideous bug*. Runlevel S is "system startup". Runlevel "1" is single user. Heck, runlevel S is not even a runlevel per se, because the system cannot be left in the "S" runlevel. It can only be transitioning *to* S state in SySV-rc statemachine terms, (i.e. bootstrapping), but as soon as it finishes that, it must immediately do a switch to the default runlevel (runlevel 2 in Debian). > Rewriting init to not use the 'S' string to indicate the singleuser > runlevel might be another, but I am not quite sure if that is a good > idea either. S has never been the single user runlevel. WTF is init doing with S that got you worried? > The more I study the boot system in debian, the more design problems I > find. For example, why are there start symlinks in rc0.d and rc6.d > used as stop symlinks, instead of renaming S* to K* and place them > where they should be in the stop sequence? And now this, the S > runlevel being both single user (according to init) and bootup > according to inittab. :/ Petter, read my paper at http://people.debian.org/~hmh/ *right* *now*. I mean it. It is outdated, but it explains a damn great deal of what happens and why. What you describe is the the truckload of crap inherited from System V, and that is something you really ought to know about. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh _______________________________________________ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-sysvinit-devel