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

[Tom Evans]

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.

Cheers

Tom

Cheers

Tom