Red Hat Bugzilla – Bug 446874
90clock does not restart ntpd due to deleted lock file
Last modified: 2015-03-04 20:19:53 EST
Description of problem:
When resuming from hibernate or suspend, the /usr/lib64/pm-utils/sleep.d/90clock
does not restart ntpd due to deleted lock file ($STORAGEDIR) as "trap
remove_suspend_lock 0" is runned before "restartservice ntpd;" checks if lock
file exists in $STORAGEDIR which has been just deleted buy remove_suspend_lock.
Patch following.. (and the ntpd stopping/restarting should on it's own file). =)
Created attachment 305696 [details]
a patch for 90clock to fix ntpd issue
Really annoying. Breaks Kerberos... eventually :-(
We could simply leave ntpd running on suspend/hibernate and then do condrestart
of the service with a delay on resume/thaw. No?
I'm not exactly sure how (should look from the source code) ntpd's internal
state would survive on resume, at least the ntpd might shutdown itself due the
clock skew before we are able to do condrestart.
Bojan: apply the patch for the first aid. =)
I already worked around the problem by putting my own 90clock in
/etc/pm/sleep.d, but thanks anyway :-)
Anyhow, even if ntpd daemon exists due to clock skew, the lock file will remain
(provided ntpd was enabled in that run level and started, of course), because
deamon won't remove the file (only the script does). So, condrestart will find
the lock file and restart ntpd.
In case ntpd was not enabled in that run level and/or wasn't running,
condrestart won't do anything.
Or did I miss something?
Sorry, not "exists", but "exits", of course.
Yeah, the lockfile remains and condrestart will work.
That's too easy. ;)
I guess you are already using condrestart?
Actually, no. When I first encountered the problem, I didn't have time to think
about it, so I just did a brute force stop/start thing in /etc/pm/sleep.d.
Just another comment on this. I think this should also stop/start ntpdate, so
that we get the clock synced ASAP on thaw/resume. It takes a while for ntpd
itself to sync to the source, so if Kerberos tickets are renewed by user during
this time (and they will be if Network Authentication is enabled in Gnome
session and it so happens that they are due for renewal), they may end up being
bad if hardware clock is too skewed. This is exactly what is happening on one of
Fixed in F10.