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