Bug 446874 - 90clock does not restart ntpd due to deleted lock file
90clock does not restart ntpd due to deleted lock file
Product: Fedora
Classification: Fedora
Component: pm-utils (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Phil Knirsch
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-05-16 11:04 EDT by Pasi Sjöholm
Modified: 2015-03-04 20:19 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-01-28 14:41:07 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
a patch for 90clock to fix ntpd issue (874 bytes, patch)
2008-05-16 11:04 EDT, Pasi Sjöholm
no flags Details | Diff

  None (edit)
Description Pasi Sjöholm 2008-05-16 11:04:07 EDT
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). =)
Comment 1 Pasi Sjöholm 2008-05-16 11:04:07 EDT
Created attachment 305696 [details]
a patch for 90clock to fix ntpd issue
Comment 2 Bojan Smojver 2008-07-03 18:43:28 EDT
Really annoying. Breaks Kerberos... eventually :-(
Comment 3 Bojan Smojver 2008-07-05 19:56:19 EDT
We could simply leave ntpd running on suspend/hibernate and then do condrestart
of the service with a delay on resume/thaw. No?
Comment 4 Pasi Sjöholm 2008-07-06 04:23:52 EDT
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. =)
Comment 5 Bojan Smojver 2008-07-06 05:08:09 EDT
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?
Comment 6 Bojan Smojver 2008-07-06 05:12:44 EDT
Sorry, not "exists", but "exits", of course.
Comment 7 Pasi Sjöholm 2008-07-06 16:34:34 EDT
Yeah, the lockfile remains and condrestart will work.
That's too easy. ;)

I guess you are already using condrestart?
Comment 8 Bojan Smojver 2008-07-06 18:54:15 EDT
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.
Comment 9 Bojan Smojver 2008-07-29 23:13:17 EDT
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
my systems.
Comment 10 Pasi Sjöholm 2009-01-28 14:41:07 EST
Fixed in F10.

Note You need to log in before you can comment on or make changes to this bug.