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

Bruce Dubbs bruce.dubbs at
Mon Jul 18 22:20:22 PDT 2011

DJ Lucas wrote:

> 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.

No, we don't have anything at RL2.  At least not now.  The BLFS Makefile

ln -sf  ../init.d/alsa ${EXTDIR}/rc.d/rc0.d/K35alsa
ln -sf  ../init.d/alsa ${EXTDIR}/rc.d/rc1.d/K35alsa
ln -sf  ../init.d/alsa ${EXTDIR}/rc.d/rc6.d/K35alsa

>> 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. 

Yes, writing to /etc for configuration is wrong.  It should write to
/var/cache/alsa or similar or more likely /home/.config/alsa/state, not
/etc.  I agree that dropping to RL1 should do this, but not RL2.  It's a
design problem in alsa.

> 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).

OK, I'll check into this and do some testing.

> 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.

Actually, I haven't done a manual change of run level is several years.
  I like to start in RL3 and stay there until shutdown.  It's easy to
type startx and the boot is a lot faster.  For those who are command
line impaired, I guess a change from RL5 to RL3 is sometimes needed, but
C-A-D for reboot and shutdown for halt is all I ever use.
I can't remember the last time I used RL1 or RL2 for any reason.

> 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). 

I already rewrote ifup/ifdown and added a way to write multiple
(optional) scripts for a single interface.  There will need some new
services written for BLFS and wireless can be complicated and a bit tricky.

> 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.

Of course I want your comments.  I do have some time now, so I can do
the writing if I know the issues.

   -- Bruce

More information about the lfs-dev mailing list