> 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
