[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Why /etc/init.d/.depend.start did not caught editing to /etc/insserv.conf?



Bob Proulx <bob <at> proulx.com> writes:

> 
> Looking at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=634215 I
> see that you have found a problem related to @reboot with cron
> starting earlier using the dependency based booting than it did before
> with the legacy based manually specified number booting.  But there
> are some missing details.
> 
> I assume that you have an action in @reboot from cron that is now
> being run before ntp is started and that your hardware clock isn't
> functioning?  Because if your hardware clock is functioning then time
> should be pretty close to correct even without ntp running.  But I
> know if your hardware clock is dead, such as from a dead battery, then
> time will be very incorrect until ntp is finished running.  I assume
> that your @reboot action is having a problem because it is running in
> this intermediate time?  Could you clarify?
> 

  Yes.  Unless I am mistaken, my @reboot problem is due to the 
intermediate time.  I don't want to reboot the machine to verify that.
I will wait for a more subtle reason to reboot.

> 
> For what it is worth I think your customization of cron to add a
> dependency is the right way to go.  Did you try adding ntp to the
> "Should-Start" list?  I think that would be better.
> 

  That is what I eventually did.  To add ntp to the Should-Start line.
A system administrator can also modify rc.local, which has $all.  I
still think that with parallel boot sequence, something should be done
about the unexpected behavior of @reboot.  A naive, or senior, user
is likely to expect all system services to be available for the 
command of @reboot.

  As an aside, with parallel boot, do the 2 digit numbers of the
scripts at each run level have any significance?  How do those 2
digit numbers determined?




Reply to: