cron(8) mis-feature with @reboot long after system startup

[Jason Hellenthal]

On Sat, Nov 26, 2011 at 07:05:00PM +0000, Chris Rees wrote:
> On 26 November 2011 19:00, Jason Hellenthal <jhell at dataix.net> wrote:
> > On Sat, Nov 26, 2011 at 06:43:38AM +0100, Michael Ross wrote:
> >> Am 26.11.2011, 06:11 Uhr, schrieb Jason Hellenthal <jhell at dataix.net>:
> >> > On Fri, Nov 25, 2011 at 10:36:40PM +0100, Christian Kastner wrote:
> >> >> Hi,
> >> >>
> >> >> On 2011-11-25 08:02, Jason Hellenthal wrote:
> >> >> > So with that said... is there a way we could actually make this run
> >> >> @reboot only ?
> >> >>
> >> >> Debian's cron[0] and Fedora's cronie[1] have solved this by touching a
> >> >> file on first startup and running @reboot only when this file does not
> >> >> yet exist.
> >> >>
> >> >> Note that while [0] may point to other patches that might be of interest
> >> >> to FreeBSD, they are still WIP (as evident from the linked patch) as we
> >> >> are still in the process of quiltifying our current code base.
> >> >>
> >> >
> >> > While this sounds like a perfectly sane way to handle the problem at
> >> > hand this also introduces a need to write some cleanup code to take care
> >> > of the file semantics. I think comparing daemon start times to the time
> >> > a system was booted or similiar would alleviate the need for all that.
> >> > Maybe a flag for @reboot "-s <seconds>" seconds after boottime to allow
> >> > running @reboot jobs. And set the default to 3600 seconds. At least this
> >> > would allow adjustment for those startup processes that may take some
> >> > considerable time before multiuser mode is entered.
> >> >
> >> > Just some thought.
> >> >
> >> > I really don't think we need to go the route of using files to store
> >> > information when there is enough information available already via
> >> > syscall's.
> >>
> >> If system startup were to be unusually delayed (dhcp or nfs trouble eg),
> >> $time_period might have passed when cron starts, so there would have to be
> >> some notifying mechanism for @reboot jobs not being run, and operator
> >> action would be required.
> >>
> >
> > I agree but also disagree. 1 hour or 3600 seconds is plenty of time to wait for the "@reboot" extension scripts to fire.
> 
> Yes, and if I restart cron 30 minutes after boot, I'm screwed.
> 

Very true. But it would still be keeping its same behavior that it has had for the last .... some odd years.

Also it should be noted that my references to using time as way to figure out if cron has been run @reboot only does have another fallback. If a system is brought into single-user mode then you would obviously want the @reboot scripts to run again since essentially everything has been brought down similiar to a reboot.

what would be nice is if the init and kernel would keep kern.init.times and create a syscall for thes so the time gets set when init goes mult-iuser. Then at least there would be something real to compare to.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20111126/e6384738/attachment.pgp