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

[Freddie Cash]

On Fri, Nov 25, 2011 at 8:37 AM, Tom Evans <tevans.uk at googlemail.com> wrote:

> On Fri, Nov 25, 2011 at 4:09 PM, Cy Schubert <Cy.Schubert at komquats.com>
> wrote:
> > 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.
>
> The problem is that the behaviour is not broken, it works exactly as
> described in crontab(5) - it is just confusing.
>
> It's also slightly nonsensical - the command isn't run at reboot, it
> is run at boot. How about leaving @reboot exactly as it is, improving
> the docs so that it is clear what @reboot does, and add a @boot to
> vixie-cron which would only run at boot time. I think it isn't wise to
> change how one strange to use format behaves under FreeBSD when
> vixie-cron is a quite ubiquitous choice amongst nix variants.
>
> With regards to anything that runs at boot, I think dumbly checking
> that the boot time was less than N minutes ago is also sub-optimal. If
> cron keeps dieing and respawning close to boot time, your cronjob
> could trigger multiple times.
>
> I don't know the exact semantics of kern.boottime - at what point is
> the boot time stored? If it is before file systems are mounted, an
> unclean file system triggering a foreground fsck could delay boot time
> by hours, thereby forcing cron to not think that it is running at boot
> time when it is finally started.
>

Perhaps a call to uptime(1) would be enough?

-- 
Freddie Cash
fjwcash at gmail.com