I've read about this multiple times in the forums and have had the issue with my own system too. Whenever you use the ntpdate command in a cronjob and it adjusts the date it ends up causing fcron to stop working until you either restart fcron or edit the crontab. I'm also willing to bet that this is a problem with all cron daemons so my thought is to make it throw an error when it comes accross that cronjob and not run it.
Can you please post the links to those forum topics? I failed to find any :-(
Running ntpdate from a cron job is not a good idea (cf. [1], [2], but most importantly [3]). [1] http://www.eecis.udel.edu/~mills/ntp/html/ntpdate.html: "It is also possible to run ntpdate from a cron script. However, it is important to note that ntpdate with contrived cron scripts is no substitute for the NTP daemon, which uses sophisticated algorithms to maximize accuracy and reliability while minimizing resource use. Finally, since ntpdate does not discipline the host clock frequency as does ntpd, the accuracy using ntpdate is limited." [2] http://developers.slashdot.org/comments.pl?sid=109436&cid=9299897 [3] http://www.ntp.org/ntpfaq/NTP-s-config.htm
Jeroen, thank you for excursion why ntpdate from cron is bad, but could you show us links where users report about the same problem? I mean fcron freeze?
(In reply to comment #3) > Jeroen, thank you for excursion why ntpdate from cron is bad, but could you > show us links where users report about the same problem? I mean fcron freeze? What do you mean by excursion? Seems completely on topic to me: don't run an NTP client from a cron job. From the generic mechanisms of both a clock driven scheduler (cron) and a crude clock setting program (the NTP client, as opposed to an NTP daemon) it should be obvious that the latter has the inherent potential to cause race conditions in the former. You might argue that a good cron implementation can handle this (but shouldn't have to) in which case it's fcron's upstream that should improve fcron. You might also argue that users should not (radically) change the clock through a program that depends on that same clock. So that's a no: I can't show you links because I guess the users who did experience such problems have figured out the source of the problem long before they started asking questions about it on forums. If you want to do anything about this bug, and you are on the cron herd this bug is assigned to, then simply close it as INVALID.
can't remember the threads from way back then, but two relevent ones http://forums.gentoo.org/viewtopic-t-400326-highlight-fcron+ntpdate.html I think it also had to do with older versions, perhaps it should be marked as invalid?
(In reply to comment #4) > What do you mean by excursion? Just this: 1 a short journey usually made for pleasure, often by a group of people 2 excursion into sth a brief involvement in a new activity (from Cambridge Advanced Learner's Dictionary) I did not mean that mentioned links are OT here. And yes. I think this is fcron's bug that is fixed in 3.x. But before we close this bug may be it's worth to add ewarn with link on ntpfaq into net-misc/ntp and also may be it's worth to add a note into cron guide. vapier what do you think about this? If you agree on this I'll CC other maintainers of packages provide ntpdate.
Hey, I saw this bug on machines a while ago, when using <fcron-3 Since I've updated I haven't had this issue. I also like to add that it wasn't an ntpdate issue. I had a machine with a really bad clock, really bad. Would lose 1.6s every 30s. I ran ntpd on this machine and even still fcron2 series would have issue, I could see a large clock adjustment right before a job was expected but never run. No other jobs would run either. Restarting fcron fixed that immediate issue. In a few days it would stop again. Eventually we got fcron3 and the problem disappeared. IIRC the changelog from 2-3 also mentions some updates about timing. In summary I think the real issue is that large clock skew confuses fcron2 series but is fixed in fcron3 - for sure in 3.0.2.
mips: care to keyword sys-process/fcron-3.0.1-r2 or 3.0.2 stable? thanks
FIXED in >=3.0.2
