> It's been a while, but I think it was how other distros at the time > were doing it. I went back and checked in February 2004 we were doing
> l1:S1:wait:/etc/rc.d/init.d/rc 1 > then. It may have been that way right from the start of LFS. My question is more about rcsysinit.d, and it hasn't always been that way. The way it was causes no confusion between rcS.d and runlevel "S". My first LFS build was 4.1 and it was this in "Installing Sysvinit-2.84", and the same in LFS-6.1 Sysvinit-2.86: "cat > /etc/inittab << "EOF" # Begin /etc/inittab id:3:initdefault: si::sysinit:/etc/rc.d/init.d/rc sysinit" > Of course, it you don't like the way we are doing the init scripts, > you are free to change them. I have. ;-) And am again. My career in computing began as a programmer and software designer. I'll share my changes when I get them finished. They're "different", but there are some improvements, IMO of course. That's what we do in the OSS community, isn't it? My design rationale is in the init.d/README suggested by init(8): "In many common versions of SysVinit the runlevel directories are setup with the idea that they kill anything that might be running which they don't want, before starting what they want to run. Each runlevel is expected to know more than it should about all previous runlevels. The problem for scripts is 'might be running'. Depending on the runlevels involved, they can't be sure if they're being asked to kill something that was never actually started, e.g. rc1 to rc0 vs rc3 to rc0. So they have to set 'lock files' or something as notes to themselves if they started anything. It's esthetically unpleasant." "In this version the idea is, 'You started it, you kill it.' Processing within a runlevel starts by starting processes, not killing them. In setting up most runlevel directories one creates the S-links for tasks to run at this runlevel, and instead of placing the corresponding K-links in up to 6 different directories, it goes in this same runlevel directory. That makes setting up the rc*.d directories MUCH simpler and less error prone. One should only have to think about killing what is still running in this runlevel. In the previous example, rc1 stops what it started, rc3 stops what it started, rc0 gets the same system state." "Knowledge of what's running is implicit in what the runlevel has started. The individual scripts are simpler. They don't need to 'remember' that they started a daemon so they can check later whether there is one to be stopped, or not. When they are called on to stop a daemon, they can safely assume that they started it. 'Entering runlevel N, I start the daemon. Leaving runlevel N, I stop it.'" If you don't think my use of rc1 is useful, given that it runs almost nothing, substitute rc5. -- Paul Rogers paulgrog...@fastmail.fm Rogers' Second Law: "Everything you do communicates." (I do not personally endorse any additions after this line. TANSTAAFL :-) -- http://www.fastmail.com - A fast, anti-spam email service. -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style