Question about the 'K' and 'S' in script names in /etc/rc.d/rc{0, 6}.d

DJ Lucas dj at
Mon Jul 18 21:18:09 PDT 2011

Moved to LFS-Dev.

On 07/17/2011 07:57 PM, Bruce Dubbs wrote:
> DJ Lucas wrote:
>> On 07/17/2011 02:51 PM, Bruce Dubbs wrote:
>>> DJ Lucas wrote:
>>>> Actually, this check needs to be removed. It causes issues for the alsa
>>>> script and also setclock (if used to set hwclock when network goes down
>>>> in RL2).
>>> Wouldn't this be just as easy as creating symlinks S50setclock in rc0
>>> and rc6 in the LFS Makefile?  In the same way, creating S35alsa symlinks
>>> in the BLFS Makefile would save the asla settings.
>> No. Drop to RL1 with alsa volumes restored via udev for an example of
>> why that block should be removed. It doesn't matter for 0 and 6 because
>> the check is skipped. It's been a while, but IIRC, the same thing for a
>> K??setclock link in RL2.
> I don't understand.  What we have now is:

<snip code>

> In rc1.d I have K30sshd, K80network, K90sysklogd, S25random.  The same
> in rc2.d.  setclock is executed in rcsysinit.

If alsa utils is installed, you should have K links in RLs 0,1,2,6 and 
no start links as the volume restore is handled by udev.

> If I add S50setclock and S40alsa to rc{0,6}.d, the '-f ${prev_start}'
> fails and the continue is never executed.  The command is run with the
> stop parameter in both cases and does the right thing, AFAICT.

Oh, actually, setclock should not be run in rcsysinit any longer. that's 
for udev to handle now as well. That is where the issue comes into play. 
The alsa script should write the volumes to disk when switching from 
runlevel 3 to runlevel 2 (no net == no usr == no alsactl) or especially 
RL1 as the rootfs might be RO, and it certainly wasn't started by a 
script in RL3, but by udev (please ignore the FHS /usr argument as we 
are still bound by it for now). You should see the same issue (not 
started in previous runlevel) if you were to put Kxxsetclock in rc2.d or 
rc1.d and telinit 2 or 1.

>> This is proper IMO when using NTP, but not really useful in practice.
> Agree, except if the hw clock is too far off, ntp is unhappy.

That is the point, to set hwclock when dropping network so that it'll be 
that much closer when you jump back into 3/4/5....probably really 
doesn't matter unless you are in RL2 overnight and system timer is way 
outta whack (in which case you have bigger problems).

> Are you suggesting that we just remove the 'if' block above?  I'd think
> that might add some strange failures at shutdown, but shouldn't hurt
> anything.

Yes, that is exactly what I was suggesting. Using S links in 0 and 6 for 
alsa does nothing for RL1 and RL2. Besides, as mentioned earlier in the 
thread, the S links in 0 and 6 _were_ intended to be reserved for very 
specific system requirements. I'm not really sure if ALSA, or anything 
outside of the base LFS for that matter, should get special treatment here.

With the LSB defined return values, it didn't matter because stopping an 
already stopped service results in a return value of 0 (an OK message). 
In the case of alsa, this doesn't even apply, you're not stopping a 
service, only writing a file, there should never be a failure here 
unless it is run late or you did something that makes /etc read only. 
Also, I don't really see how we could get a bunch of warning/error 
messages with current scripts (though I haven't really used the stock 
scripts for more than a few minutes at a time since 2006). Everything 
installed by the books is handled in all 7 runlevels or sysinit, with a 
few exceptions, notably the two above (and only alsa is mentioned in 
either of the books).

The prevlevl check has simply been outdated by modern tools (udev). 
Going back to the LSB return values mentioned above, the warning 
messages about items not running at shutdown are not really useful. I 
mean, what can you do about it at that point? Same thing for the "not 
started in previous runlevel" message...just exit 0 and paint a pretty 
green message on the screen. If the pid file checks are rewritten, again 
I'll refer to the LSB scripts pidofproc(), you can simply bypass the 
execution and exit 0. This also fixes the issue with the apache script 
killing children first.

Again, I don't particularly like it (yet), but I have a feeling that 
we'll begin to see more and more of this in the future. Network cards 
could conceivably be next in line (think of turning on your wireless 
card on your laptop), so it makes some sense to rewrite ifup and ifdown 
now, along with the network script (which could be also be replaced by 
NM or something similar after LFS). As much can be reused in the future, 
the better. Of course, I could be very wrong in my prediction, but I 
figure rather than introduce a couple of corner cases, you should 
probably go ahead and nip what we can in the bud now while you are 
familiar with the work that needs to be done.

Free time is still not what it should be for me right now, but I'll jump 
in an make some comments on your changes (if needed/wanted) as soon as I 
have time to install and test.

-- DJ Lucas

This message has been scanned for viruses and
dangerous content, and is believed to be clean.

More information about the lfs-dev mailing list