El 2012-09-22 a las 12:42 -0700, unruh escribió: (resending to the list)
> In linux.debian.user, you wrote: (...) > >> >> It seems not ntp problem but a kernel bug: > >> >> > >> >> http://my.opera.com/marcomarongiu/blog/2010/08/18/debugging-ntp-again-part-4-and-last > >> > > >> > You can try the mentioned work-around and see if that works for you. > >> > > >> > Anyway, if that's the case, you should experience the same with different > >> > ntp daemons and not just with ntpd :-? > >> > >> I've experienced the same problem also with openntp. > > > > That makes more sense. > > > > Anyway, no NTP daemon should crash because of skewed time; one thing is > > that it refushes to sync (which can be fine, and should log this fact > > so the admin can make the proper measures) but a different thing is > > completely killing the service. > > One of the features of ntpd-- as stated in the documentation-- is that > if the time is too far out, ntpd will put a warning into the log file > and exit/quit. If that happens the attitude of Mills is that something > is very seriously wrong, and the best thing that ntpd can do is to quit, > and let a human fix theproblem. It does not crash. It quits in an > orderly fashion. If you want something that does not quit, and does not > have the 500PPM limit of clock slewing, get chrony. Yes, thanks for the hints. It seems to be in the end a software design restriction which makes not much sense to me. A software delevoper should understand that an exited daemon is of no help neither for an admin human being nor for an automated system: quitting is the worst a process can do and not only because a needed service is stopped but also because no logs and no more information will be provided. Nothing. On the other hand, I guess ntpd can be configured to sync with remote servers at predefined interval (i.e., 5 or 12 minutes) that way, unless the host clock is badly broken, the time will be kept synced. > >> Now I'm back with ntp using the workaround mentioned, hope it works. > > > > Perfect, tell us how it went. > > IF the clock really does jump suddenly by an hour, it will never work. Well, I think the work-around is precissely to avoid the kernel from going nuts with the time. Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120923155824.ga5...@stt008.linux.site
