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

[Cy Schubert]

In message <4ECF54F1.50203 at FreeBSD.org>, Doug Barton writes:
> On 11/25/2011 00:12, Cy Schubert wrote:
> > In message <20111125070241.GA7915 at DataIX.net>, Jason Hellenthal writes:
> >> List,
> >>
> >> When using @reboot with cron you expect your proccesses to always start wh
> en 
> >> the system boots up and only when the system boots. But long after the sys
> tem
> >>  in question had been booted, my @reboot processes ran again! after a (/et
> c/r
> >> c.d/cron restart). This is normally fine and dandy until one of your @rebo
> ot 
> >> jobs needs to contain a process that purges files "files that are already 
> in 
> >> use by a running daemon since the system has not rebooted" and becomes haz
> ard
> >> ous.
> >>
> >> So with that said... is there a way we could actually make this run @reboo
> t o
> >> nly ?
> >>
> >> Compare the system boottime (kern.boottime) to the current time and if it 
> is 
> >> greater than ?5 minutes? do not run on any @reboot's ? or add yet another 
> ext
> >> ension @boottime so it does not throw off current functionality ?
> >>
> >> Surely I could modify the scripts which do this but I find it unproductive
>  an
> >> d counter intuitive for the need to explain that @reboot means "When cron 
> is 
> >> restarted" even though the name means something completely opposite.
> > 
> > I don't see how cron could run reboot jobs again while running. It calls 
> > run_reboot_jobs only during startup. Could it be possible that cron died on
>  
> > your system and you restarted it?
> 
> Please read the OP again carefully.

You're right. Sorry. It was late, after a long night of O/T.

Let's try this again....

Add an option to cron to check lastlog and if within 5 or 10 minutes of the 
last reboot, then call run_reboot_jobs().

Alternatively, any cron job that needed to run after reboot could do this 
itself.

Changing the behaviour by default would change the semantics of @reboot, 
altering  the behaviour of cron jobs which rely on the brokenness. What if 
both behaviours are wanted on the same system? Unlikely, as I can't see 
anyone relying on this broken behaviour. Having said that, I'm sure there 
are cron jobs that do rely on the broken behaviour, so it may be best to 
simply deprecate the broken behaviour and make one or the other a command 
line option.

Apologies for not reading the original posting carefully.


-- 
Cheers,
Cy Schubert <Cy.Schubert at komquats.com>
FreeBSD UNIX:  <cy at FreeBSD.org>   Web:  http://www.FreeBSD.org