On Fri, Nov 25, 2011 at 4:09 PM, Cy Schubert <cy.schub...@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 _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
