On Thu, Nov 28, Carlos E. R. wrote:
And what happens if ntp is not restarted inmediately after resume? looks like a bug, is there a bug report about that?
No idea if there is a bug report. I'm sure it is working as designed, time servers should not be ever powered off, after all. Hibernating is not the proper thing to do in that scenario - it is a different scenario.
The ntpd running on systems doing suspend/resume is more a client than a server. And even an upstream server will probably go down for maintenence. So there must be ways to recover from hickups.
On restore from hibernation it just tries to keep sync with previous time servers, but the clock is no longer in exact sync. It the difference is large it can take many hours to sync again, or even abort and exit. A restart ensures that you get the right pool of servers, that it does a step sync, then starts the daemon.
Since on resume the time is kind of undefined, and in addition an unavoidable timejump happens anyway. it would be good if the systemtime would at least be forced to be correct by restarting ntpd and letting it grab time from remote. Like you said.
Another example: dovecot. It strongly dislikes clock changes, it can crash on them. It prints warning and errors after hibernation:
<2.4> 2013-11-28 14:00:09 Telcontar dovecot - - - imap: Warning: Time jumped forwards 28271 seconds <2.4> 2013-11-28 14:00:09 Telcontar dovecot - - - imap: Warning: Time jumped forwards 28407 seconds <2.4> 2013-11-28 14:00:09 Telcontar dovecot - - - imap: Warning: Time jumped forwards 30034 seconds
Thats likely a wrong expectation of dovecot. If the logs above really come from suspend/resume cycles it just tells that its not suspend/resume aware. Perhaps the wrappers around suspend/resume can stop and start the service to work around this shortcoming within dovecot. Olaf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org