Re: cron(8) mis-feature with @reboot long after system startup
On 26 November 2011 07:25, Doug Barton do...@freebsd.org wrote: On 11/25/2011 23:08, Cy Schubert wrote: If average users really do need to run something at boot they're likely running some kind of service I don't think second-guessing what users are doing is going to be a useful exercise here. I will also tell you flat out that this is not the only use for an @reboot cron job. Rather than debating whether users *should* be doing it this way or not, can we please focus on fixing it to be non-stupid? +1 hat class=armchair-general I find the idea of using time since boot to decide whether this is cron's first startup repellent in the extreme. Whatever solution is decided (and I'm thinking a variable passed to rc.d/cron or a state file in /var/run would both work fine), PLEASE let's not go down the route of that. How long? What if I need to restart cron shortly after boot? What if boot takes longer? /hat Plenty of competent coders in here, but please consider me interested in helping with a solution if needed. Chris ___ 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
Re: cron(8) mis-feature with @reboot long after system startup
Am 26.11.2011, 06:11 Uhr, schrieb Jason Hellenthal jh...@dataix.net: On Fri, Nov 25, 2011 at 10:36:40PM +0100, Christian Kastner wrote: Hi, On 2011-11-25 08:02, Jason Hellenthal wrote: So with that said... is there a way we could actually make this run @reboot only ? Debian's cron[0] and Fedora's cronie[1] have solved this by touching a file on first startup and running @reboot only when this file does not yet exist. Note that while [0] may point to other patches that might be of interest to FreeBSD, they are still WIP (as evident from the linked patch) as we are still in the process of quiltifying our current code base. While this sounds like a perfectly sane way to handle the problem at hand this also introduces a need to write some cleanup code to take care of the file semantics. I think comparing daemon start times to the time a system was booted or similiar would alleviate the need for all that. Maybe a flag for @reboot -s seconds seconds after boottime to allow running @reboot jobs. And set the default to 3600 seconds. At least this would allow adjustment for those startup processes that may take some considerable time before multiuser mode is entered. Just some thought. I really don't think we need to go the route of using files to store information when there is enough information available already via syscall's. If system startup were to be unusually delayed (dhcp or nfs trouble eg), $time_period might have passed when cron starts, so there would have to be some notifying mechanism for @reboot jobs not being run, and operator action would be required. One could cron restart within $time_period and run @reboot twice. I don't like this idea. In my bikeshed, @reboot should be called @cronstart, but it shouldn't because of uniformity across OSs. The cron manpage should reflect the actual behaviour (already patched in svn), and all definitely only on boot-scripts should go in local/etc/rc.d. Michael ___ 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
Re: cron(8) mis-feature with @reboot long after system startup
Am 26.11.2011 um 11:54 schrieb Chris Rees: PLEASE let's not go down the route of that. How long? What if I need to restart cron shortly after boot? What if boot takes longer? Plus interesting time changes during boot due to ntpdate/ntpd. -- Stefan Bethke s...@lassitu.de Fon +49 151 14070811 ___ 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
Re: cron(8) mis-feature with @reboot long after system startup
On Sat, Nov 26, 2011 at 06:43:38AM +0100, Michael Ross wrote: Am 26.11.2011, 06:11 Uhr, schrieb Jason Hellenthal jh...@dataix.net: On Fri, Nov 25, 2011 at 10:36:40PM +0100, Christian Kastner wrote: Hi, On 2011-11-25 08:02, Jason Hellenthal wrote: So with that said... is there a way we could actually make this run @reboot only ? Debian's cron[0] and Fedora's cronie[1] have solved this by touching a file on first startup and running @reboot only when this file does not yet exist. Note that while [0] may point to other patches that might be of interest to FreeBSD, they are still WIP (as evident from the linked patch) as we are still in the process of quiltifying our current code base. While this sounds like a perfectly sane way to handle the problem at hand this also introduces a need to write some cleanup code to take care of the file semantics. I think comparing daemon start times to the time a system was booted or similiar would alleviate the need for all that. Maybe a flag for @reboot -s seconds seconds after boottime to allow running @reboot jobs. And set the default to 3600 seconds. At least this would allow adjustment for those startup processes that may take some considerable time before multiuser mode is entered. Just some thought. I really don't think we need to go the route of using files to store information when there is enough information available already via syscall's. If system startup were to be unusually delayed (dhcp or nfs trouble eg), $time_period might have passed when cron starts, so there would have to be some notifying mechanism for @reboot jobs not being run, and operator action would be required. I agree but also disagree. 1 hour or 3600 seconds is plenty of time to wait for the @reboot extension scripts to fire. One could cron restart within $time_period and run @reboot twice. I don't like this idea. In my bikeshed, @reboot should be called @cronstart, but it shouldn't because of uniformity across OSs. The cron manpage should reflect the actual behaviour (already patched in svn), and all definitely only on boot-scripts should go in local/etc/rc.d. This has nothing to do with rc.d. This is a cron(8) problem only. ___ 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
Re: cron(8) mis-feature with @reboot long after system startup
On 26 November 2011 19:00, Jason Hellenthal jh...@dataix.net wrote: On Sat, Nov 26, 2011 at 06:43:38AM +0100, Michael Ross wrote: Am 26.11.2011, 06:11 Uhr, schrieb Jason Hellenthal jh...@dataix.net: On Fri, Nov 25, 2011 at 10:36:40PM +0100, Christian Kastner wrote: Hi, On 2011-11-25 08:02, Jason Hellenthal wrote: So with that said... is there a way we could actually make this run @reboot only ? Debian's cron[0] and Fedora's cronie[1] have solved this by touching a file on first startup and running @reboot only when this file does not yet exist. Note that while [0] may point to other patches that might be of interest to FreeBSD, they are still WIP (as evident from the linked patch) as we are still in the process of quiltifying our current code base. While this sounds like a perfectly sane way to handle the problem at hand this also introduces a need to write some cleanup code to take care of the file semantics. I think comparing daemon start times to the time a system was booted or similiar would alleviate the need for all that. Maybe a flag for @reboot -s seconds seconds after boottime to allow running @reboot jobs. And set the default to 3600 seconds. At least this would allow adjustment for those startup processes that may take some considerable time before multiuser mode is entered. Just some thought. I really don't think we need to go the route of using files to store information when there is enough information available already via syscall's. If system startup were to be unusually delayed (dhcp or nfs trouble eg), $time_period might have passed when cron starts, so there would have to be some notifying mechanism for @reboot jobs not being run, and operator action would be required. I agree but also disagree. 1 hour or 3600 seconds is plenty of time to wait for the @reboot extension scripts to fire. Yes, and if I restart cron 30 minutes after boot, I'm screwed. Chris ___ 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
Re: cron(8) mis-feature with @reboot long after system startup
On Sat, Nov 26, 2011 at 07:05:00PM +, Chris Rees wrote: On 26 November 2011 19:00, Jason Hellenthal jh...@dataix.net wrote: On Sat, Nov 26, 2011 at 06:43:38AM +0100, Michael Ross wrote: Am 26.11.2011, 06:11 Uhr, schrieb Jason Hellenthal jh...@dataix.net: On Fri, Nov 25, 2011 at 10:36:40PM +0100, Christian Kastner wrote: Hi, On 2011-11-25 08:02, Jason Hellenthal wrote: So with that said... is there a way we could actually make this run @reboot only ? Debian's cron[0] and Fedora's cronie[1] have solved this by touching a file on first startup and running @reboot only when this file does not yet exist. Note that while [0] may point to other patches that might be of interest to FreeBSD, they are still WIP (as evident from the linked patch) as we are still in the process of quiltifying our current code base. While this sounds like a perfectly sane way to handle the problem at hand this also introduces a need to write some cleanup code to take care of the file semantics. I think comparing daemon start times to the time a system was booted or similiar would alleviate the need for all that. Maybe a flag for @reboot -s seconds seconds after boottime to allow running @reboot jobs. And set the default to 3600 seconds. At least this would allow adjustment for those startup processes that may take some considerable time before multiuser mode is entered. Just some thought. I really don't think we need to go the route of using files to store information when there is enough information available already via syscall's. If system startup were to be unusually delayed (dhcp or nfs trouble eg), $time_period might have passed when cron starts, so there would have to be some notifying mechanism for @reboot jobs not being run, and operator action would be required. I agree but also disagree. 1 hour or 3600 seconds is plenty of time to wait for the @reboot extension scripts to fire. Yes, and if I restart cron 30 minutes after boot, I'm screwed. Very true. But it would still be keeping its same behavior that it has had for the last some odd years. Also it should be noted that my references to using time as way to figure out if cron has been run @reboot only does have another fallback. If a system is brought into single-user mode then you would obviously want the @reboot scripts to run again since essentially everything has been brought down similiar to a reboot. what would be nice is if the init and kernel would keep kern.init.times and create a syscall for thes so the time gets set when init goes mult-iuser. Then at least there would be something real to compare to. pgpCe04Cxw9vH.pgp Description: PGP signature
Re: cron(8) mis-feature with @reboot long after system startup
On Sat, Nov 26, 2011 at 04:44:20PM +0100, Stefan Bethke wrote: Am 26.11.2011 um 11:54 schrieb Chris Rees: PLEASE let's not go down the route of that. How long? What if I need to restart cron shortly after boot? What if boot takes longer? Plus interesting time changes during boot due to ntpdate/ntpd. Though it is related to when cron(8) runs jobs, in itself is not the problem. If you have interesting time changes that far off, then you have serious 'other' problems on your hands than what we are discussing. That would be for another thread. pgpA6mfMnS7zz.pgp Description: PGP signature
Re: cron(8) mis-feature with @reboot long after system startup
On Fri, Nov 25, 2011 at 12:53:43PM -0500, Dieter BSD wrote: The system doesn't go multiuser until the rc jobs complete, even if you attempt to background them with ''. ??This can be a problem with long running jobs. ??I started using cron @reboot for this reason. I haven't run into the problem since I've never needed to run /etc/rc.d/cron restart. Yeah I have never ran into this either throughout all my use cases. cron(8) has always ran and stayed running until my OP where I found out the hardway. Would make someone proud to be called Paul Vixie. ;) Add an option to cron to check lastlog and if within 5 or 10 minutes of the last reboot, then call run_reboot_jobs(). Depending on timestamps might be okay as a temporary quick-and-dirty workaround, but there is likely to be a case where it will also do the wrong thing. ??What if you need to restart cron within the 5-10 minutes? Maybe something like: rc script sets a flag, cron_reboot script checks and resets flag. ??The flag could be a file ( /tmp/rebooting_system). Better yet, a run-the-reboot-script command line option could be added to cron. cron(8) already creates a pid file. Maybe it wouldn't be so bad to just check the timestamp of that before creating its new pid file along with comparing to system boottime so we could make an accurate measure whether it should or should not run the @reboot extension at least down to 1 minute. ___ 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 pgpnUfmcetACw.pgp Description: PGP signature
Re: cron(8) mis-feature with @reboot long after system startup
On Fri, Nov 25, 2011 at 4:36 PM, Christian Kastner deb...@kvr.at wrote: Hi, On 2011-11-25 08:02, Jason Hellenthal wrote: So with that said... is there a way we could actually make this run @reboot only ? Debian's cron[0] and Fedora's cronie[1] have solved this by touching a file on first startup and running @reboot only when this file does not yet exist. I like this idea, however it has a major caveat: Assuming the shutdown scripts remove said file (and the boot scripts create said file), what happens in the event that the disk was umount'ed uncleanly? For example, a power failure (I know, that's what UPSs are for, but lets ignore that for a second). If the system is configured to automatically boot after a power failure, the @reboot cron script wont run (since the said file still exists...). ___ 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
Re: cron(8) mis-feature with @reboot long after system startup
On Sat, Nov 26, 2011 at 02:58:46PM -0500, APseudoUtopia wrote: On Fri, Nov 25, 2011 at 4:36 PM, Christian Kastner deb...@kvr.at wrote: On 2011-11-25 08:02, Jason Hellenthal wrote: So with that said... is there a way we could actually make this run @reboot only ? Debian's cron[0] and Fedora's cronie[1] have solved this by touching a file on first startup and running @reboot only when this file does not yet exist. I like this idea, however it has a major caveat: Assuming the shutdown scripts remove said file (and the boot scripts create said file), what happens in the event that the disk was umount'ed uncleanly? For example, a power failure (I know, that's what UPSs are for, but lets ignore that for a second). If the system is configured to automatically boot after a power failure, the @reboot cron script wont run (since the said file still exists...). The file can be stored in /var/run, which is cleared at boot. -- Jilles Tjoelker ___ 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
Re: cron(8) mis-feature with @reboot long after system startup
Add an option to cron to check lastlog and if within 5 or 10 minutes of the last reboot, then call run_reboot_jobs(). Depending on timestamps might be okay as a temporary quick-and-dirty workaround, but there is likely to be a case where it will also do the wrong thing. ??What if you need to restart cron within the 5-10 minutes? Maybe something like: rc script sets a flag, cron_reboot script checks and resets flag. ??The flag could be a file ( /tmp/rebooting_system). Better yet, a run-the-reboot-script command line option could be added to cron. cron(8) already creates a pid file. Maybe it wouldn't be so bad to just check the timestamp of that before creating its new pid file along with comparing to system boottime so we could make an accurate measure whether it should or should not run the @reboot extension at least down to 1 minute. Timing-based approaches like this tend to be brittle and fail in strange ways. Remember that boot time basically means run by /etc/rc. Is there any way for /etc/rc.d/cron to notice that it's being run by /etc/rc and pass an extra flag to cron in that case? (If not, then perhaps /etc/rc should set some kind of marker when it starts --- such as an environment variable or a file on disk --- that scripts such as /etc/rc.d/cron can use to distinguish boot-time startup from manual startup.) Tim ___ 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
Re: cron(8) mis-feature with @reboot long after system startup
In message 2025070241.ga7...@dataix.net, Jason Hellenthal writes: List, When using @reboot with cron you expect your proccesses to always start when the system boots up and only when the system boots. But long after the system in question had been booted, my @reboot processes ran again! after a (/etc/r c.d/cron restart). This is normally fine and dandy until one of your @reboot 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 hazard ous. So with that said... is there a way we could actually make this run @reboot 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? -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org ___ 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
Re: cron(8) mis-feature with @reboot long after system startup
Am 25.11.2011 um 08:02 schrieb Jason Hellenthal: When using @reboot with cron you expect your proccesses to always start when the system boots up and only when the system boots. But long after the system in question had been booted, my @reboot processes ran again! after a (/etc/rc.d/cron restart). This is normally fine and dandy until one of your @reboot 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 hazardous. So with that said... is there a way we could actually make this run @reboot only ? I didn't even know cron had this feature. Why wouldn't you add custom rc.d scripts for these tasks, or add the commands to rc.local? Stefan -- Stefan Bethke s...@lassitu.de Fon +49 151 14070811 ___ 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
Re: cron(8) mis-feature with @reboot long after system startup
On 11/25/2011 00:12, Cy Schubert wrote: In message 2025070241.ga7...@dataix.net, Jason Hellenthal writes: List, When using @reboot with cron you expect your proccesses to always start when the system boots up and only when the system boots. But long after the system in question had been booted, my @reboot processes ran again! after a (/etc/r c.d/cron restart). This is normally fine and dandy until one of your @reboot 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 hazard ous. So with that said... is there a way we could actually make this run @reboot 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. -- We could put the whole Internet into a book. Too practical. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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
Re: cron(8) mis-feature with @reboot long after system startup
On 11/25/2011 00:29, Stefan Bethke wrote: I didn't even know cron had this feature. Why wouldn't you add custom rc.d scripts for these tasks, or add the commands to rc.local? Personally I find this feature very useful for unprivileged users to do their own stuff at startup. Doug -- We could put the whole Internet into a book. Too practical. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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
Re: cron(8) mis-feature with @reboot long after system startup
On Fri, Nov 25, 2011 at 7:02 AM, Jason Hellenthal jh...@dataix.net wrote: List, When using @reboot with cron you expect your proccesses to always start when the system boots up and only when the system boots. But long after the system in question had been booted, my @reboot processes ran again! after a (/etc/rc.d/cron restart). This is normally fine and dandy until one of your @reboot 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 hazardous. So with that said... is there a way we could actually make this run @reboot only ? 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 extension @boottime so it does not throw off current functionality ? Surely I could modify the scripts which do this but I find it unproductive and counter intuitive for the need to explain that @reboot means When cron is restarted even though the name means something completely opposite. Regards Happy Thanks Giving. Yep, @reboot is super dangerous if you don't realise it is 'crond reboot' not 'system reboot'. We went through a period where all our production servers crond kept dieing and getting restarted at odd times. The simplest solution is to not run stuff you want to run at boot time through cron, and instead use rc.d, which is designed to do this. 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
Re: cron(8) mis-feature with @reboot long after system startup
In message 4ecf54f1.50...@freebsd.org, Doug Barton writes: On 11/25/2011 00:12, Cy Schubert wrote: In message 2025070241.ga7...@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.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org ___ 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
Re: cron(8) mis-feature with @reboot long after system startup
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
Re: cron(8) mis-feature with @reboot long after system startup
On Fri, Nov 25, 2011 at 8:37 AM, Tom Evans tevans...@googlemail.com wrote: 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. Perhaps a call to uptime(1) would be enough? -- Freddie Cash fjwc...@gmail.com ___ 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
Re: cron(8) mis-feature with @reboot long after system startup
The system doesn't go multiuser until the rc jobs complete, even if you attempt to background them with ''. This can be a problem with long running jobs. I started using cron @reboot for this reason. I haven't run into the problem since I've never needed to run /etc/rc.d/cron restart. Add an option to cron to check lastlog and if within 5 or 10 minutes of the last reboot, then call run_reboot_jobs(). Depending on timestamps might be okay as a temporary quick-and-dirty workaround, but there is likely to be a case where it will also do the wrong thing. What if you need to restart cron within the 5-10 minutes? Maybe something like: rc script sets a flag, cron_reboot script checks and resets flag. The flag could be a file ( /tmp/rebooting_system). Better yet, a run-the-reboot-script command line option could be added to cron. ___ 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
Re: cron(8) mis-feature with @reboot long after system startup
On Fri, 25 Nov 2011, Tom Evans wrote: 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. But crontab(5) just says startup, when really it means cron startup, so: http://svnweb.freebsd.org/base?view=revisionrevision=227981 It's also slightly nonsensical - the command isn't run at reboot, it is run at boot. It isn't just at boot, even. Really it should be called @cronstart. But that ship probably sailed a long time ago. A better alias could be added and @reboot marked as deprecated. (This does not address the technical problem of really only running something at system startup. IMHO, rc scripts are a better fit for that.)___ 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
Re: cron(8) mis-feature with @reboot long after system startup
On 11/25/2011 08:09, Cy Schubert wrote: You're right. Sorry. It was late, after a long night of O/T. Actually I was in the same boat, which is why my reply was even grumpier than usual, sorry. Meanwhile I like your suggestion of having cron check that it's within $time_period before running the @reboot jobs. I'm not quite so sure that the current behavior needs to be preserved though ... I doubt people purposely restart cron often enough to be anything but surprised by the current behavior. Doug -- We could put the whole Internet into a book. Too practical. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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
Re: cron(8) mis-feature with @reboot long after system startup
Hi, On 2011-11-25 08:02, Jason Hellenthal wrote: So with that said... is there a way we could actually make this run @reboot only ? Debian's cron[0] and Fedora's cronie[1] have solved this by touching a file on first startup and running @reboot only when this file does not yet exist. Note that while [0] may point to other patches that might be of interest to FreeBSD, they are still WIP (as evident from the linked patch) as we are still in the process of quiltifying our current code base. Regards, Christian [0] http://anonscm.debian.org/gitweb/?p=pkg-cron/pkg-cron.git;a=blob;f=debian/patches/features/run-on-reboot;h=94bab7dcbc4b34e4686385ca3ba3037453f1f4bb;hb=refs/heads/sf3 [1] http://git.fedorahosted.org/git/?p=cronie.git;a=commitdiff;h=2abb46f60f496e2725333a86ade0f3913981761d ___ 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
Re: cron(8) mis-feature with @reboot long after system startup
On Nov 25, 2011, at 2:08 PM, Doug Barton wrote: On 11/25/2011 08:09, Cy Schubert wrote: You're right. Sorry. It was late, after a long night of O/T. Actually I was in the same boat, which is why my reply was even grumpier than usual, sorry. Meanwhile I like your suggestion of having cron check that it's within $time_period before running the @reboot jobs Hmmm… I thought rc.d distinguished between boot-time and non-boot-time starts already. It might be simpler and more accurate to add a crond command-line option (--run-reboot-scripts) and have the rc.d scripts only pass that in when crond is started at boot time. Tim ___ 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
Re: cron(8) mis-feature with @reboot long after system startup
On 11/25/2011 16:16, Tim Kientzle wrote: On Nov 25, 2011, at 2:08 PM, Doug Barton wrote: On 11/25/2011 08:09, Cy Schubert wrote: You're right. Sorry. It was late, after a long night of O/T. Actually I was in the same boat, which is why my reply was even grumpier than usual, sorry. Meanwhile I like your suggestion of having cron check that it's within $time_period before running the @reboot jobs Hmmm… I thought rc.d distinguished between boot-time and non-boot-time starts already. Well sure, rc.d does, but /usr/sbin/crond doesn't. It might be simpler and more accurate to add a crond command-line option (--run-reboot-scripts) and have the rc.d scripts only pass that in when crond is started at boot time. No, since that wouldn't help if the user started it without rc.d, and more importantly, the current behavior is broken. :) Doug -- We could put the whole Internet into a book. Too practical. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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
Re: cron(8) mis-feature with @reboot long after system startup
On Fri, Nov 25, 2011 at 10:36:40PM +0100, Christian Kastner wrote: Hi, On 2011-11-25 08:02, Jason Hellenthal wrote: So with that said... is there a way we could actually make this run @reboot only ? Debian's cron[0] and Fedora's cronie[1] have solved this by touching a file on first startup and running @reboot only when this file does not yet exist. Note that while [0] may point to other patches that might be of interest to FreeBSD, they are still WIP (as evident from the linked patch) as we are still in the process of quiltifying our current code base. While this sounds like a perfectly sane way to handle the problem at hand this also introduces a need to write some cleanup code to take care of the file semantics. I think comparing daemon start times to the time a system was booted or similiar would alleviate the need for all that. Maybe a flag for @reboot -s seconds seconds after boottime to allow running @reboot jobs. And set the default to 3600 seconds. At least this would allow adjustment for those startup processes that may take some considerable time before multiuser mode is entered. Just some thought. I really don't think we need to go the route of using files to store information when there is enough information available already via syscall's. [0] http://anonscm.debian.org/gitweb/?p=pkg-cron/pkg-cron.git;a=blob;f=debian/patches/features/run-on-reboot;h=94bab7dcbc4b34e4686385ca3ba3037453f1f4bb;hb=refs/heads/sf3 [1] http://git.fedorahosted.org/git/?p=cronie.git;a=commitdiff;h=2abb46f60f496e2725333a86ade0f3913981761d pgpbttLlXo4nz.pgp Description: PGP signature
Re: cron(8) mis-feature with @reboot long after system startup
In message alpine.bsf.2.00.251042110.80...@wonkity.com, Warren Block writ es: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---902635197-1839580335-1322243619=:80691 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Fri, 25 Nov 2011, Tom Evans wrote: On Fri, Nov 25, 2011 at 4:09 PM, Cy Schubert cy.schub...@komquats.com wro te: 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. But crontab(5) just says startup, when really it means cron startup, so: http://svnweb.freebsd.org/base?view=revisionrevision=227981 It's also slightly nonsensical - the command isn't run at reboot, it is run at boot. It isn't just at boot, even. Really it should be called @cronstart. But that ship probably sailed a long time ago. A better alias could be added and @reboot marked as deprecated. (This does not address the technical problem of really only running something at system startup. IMHO, rc scripts are a better fit for that.) Agreed, that's what rc scripts are for. OTOH, a non-root user can't create rc scripts. Having said that, any non-root rc scripts I've ever run always required negotiation, e.g. oracle and other apps. You want to start other apps in a specified order. When running non-root rc scripts, it's a simple matter of, /bin/su - oracle -c '/home/oracle/product/oracle-8i/bin/startup.sh' If average users really do need to run something at boot they're likely running some kind of service, e.g. some kind of DBMS, on the machine and that would usually if not always require some kind of cooperation with the sysadmin. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org ___ 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
Re: cron(8) mis-feature with @reboot long after system startup
On 11/25/2011 23:08, Cy Schubert wrote: If average users really do need to run something at boot they're likely running some kind of service I don't think second-guessing what users are doing is going to be a useful exercise here. I will also tell you flat out that this is not the only use for an @reboot cron job. Rather than debating whether users *should* be doing it this way or not, can we please focus on fixing it to be non-stupid? -- We could put the whole Internet into a book. Too practical. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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
cron(8) mis-feature with @reboot long after system startup
List, When using @reboot with cron you expect your proccesses to always start when the system boots up and only when the system boots. But long after the system in question had been booted, my @reboot processes ran again! after a (/etc/rc.d/cron restart). This is normally fine and dandy until one of your @reboot 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 hazardous. So with that said... is there a way we could actually make this run @reboot only ? 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 extension @boottime so it does not throw off current functionality ? Surely I could modify the scripts which do this but I find it unproductive and counter intuitive for the need to explain that @reboot means When cron is restarted even though the name means something completely opposite. Regards Happy Thanks Giving. pgpSeqyEuq0xZ.pgp Description: PGP signature
