Date: Fri, 25 Nov 2011 08:40:24 -0800 From: Freddie Cash <fjwcash@gmail.com> To: Tom Evans <tevans.uk@googlemail.com> Cc: hackers@freebsd.org Subject: Re: cron(8) mis-feature with @reboot long after system startup Message-ID: <CAOjFWZ5yzrmxeJC4sO%2B77S0wwM3MPW5rGWgzA-rFDeEUmsU40Q@mail.gmail.com> In-Reply-To: <CAFHbX1JepyBHW8=YrpCU%2BPHtCJ_EruPdYgkT83x3eY317Cucnw@mail.gmail.com> References: <dougb@FreeBSD.org> <4ECF54F1.50203@FreeBSD.org> <201111251609.pAPG97dT008848@slippy.cwsent.com> <CAFHbX1JepyBHW8=YrpCU%2BPHtCJ_EruPdYgkT83x3eY317Cucnw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Nov 25, 2011 at 8:37 AM, Tom Evans <tevans.uk@googlemail.com> wrote: > On Fri, Nov 25, 2011 at 4:09 PM, Cy Schubert <Cy.Schubert@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@gmail.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOjFWZ5yzrmxeJC4sO%2B77S0wwM3MPW5rGWgzA-rFDeEUmsU40Q>