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
has:
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
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
