Bug 446874 - 90clock does not restart ntpd due to deleted lock file
Summary: 90clock does not restart ntpd due to deleted lock file
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: pm-utils
Version: 9
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Phil Knirsch
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-05-16 15:04 UTC by Pasi Sjöholm
Modified: 2015-03-05 01:19 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-01-28 19:41:07 UTC
Type: ---
Embargoed:


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

Description Pasi Sjöholm 2008-05-16 15:04:07 UTC
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 15:04:07 UTC
Created attachment 305696 [details]
a patch for 90clock to fix ntpd issue

Comment 2 Bojan Smojver 2008-07-03 22:43:28 UTC
Really annoying. Breaks Kerberos... eventually :-(

Comment 3 Bojan Smojver 2008-07-05 23:56:19 UTC
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 08:23:52 UTC
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 09:08:09 UTC
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 09:12:44 UTC
Sorry, not "exists", but "exits", of course.

Comment 7 Pasi Sjöholm 2008-07-06 20:34:34 UTC
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 22:54:15 UTC
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-30 03:13:17 UTC
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 19:41:07 UTC
Fixed in F10.


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