Your message dated Thu, 12 Nov 2009 08:38:18 +0100
with message-id <[email protected]>
and subject line Re: Bug#542923: pm-utils: ntpd not restarted at suspend/resume
has caused the Debian Bug report #542923,
regarding pm-utils: ntpd not restarted at suspend/resume
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
542923: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=542923
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: pm-utils
Version: 1.1.2.4-1
Severity: normal
Due to a typo in /usr/lib/pm-utils/sleep.d/90clock the ntp daemon is not
restarted at suspend/resume.
-- System Information:
Debian Release: 5.0.2
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.30-bpo.1-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages pm-utils depends on:
ii console-tools 1:0.2.3dbs-65.1 Linux console and font utilities
ii powermgmt-base 1.30+nmu1 Common utils and configs for power
Versions of packages pm-utils recommends:
ii hal 0.5.11-8 Hardware Abstraction Layer
ii radeontool 1.5-5 utility to control ATI Radeon back
pn uswsusp <none> (no description available)
ii vbetool 1.0-3 run real-mode video BIOS code to a
Versions of packages pm-utils suggests:
ii cpufrequtils 004-2 utilities to deal with the cpufreq
-- no debconf information
--- /usr/lib/pm-utils/sleep.d/90clock.orig 2009-08-22 11:05:21.000000000
+0200
+++ /usr/lib/pm-utils/sleep.d/90clock 2009-08-22 11:05:35.000000000 +0200
@@ -12,7 +12,7 @@
{
if try_lock "${NTPD_LOCK}"; then
trap 'release_lock "${NTPD_LOCK}"' 0
- stopservice ntpd
+ stopservice ntp
fi
/sbin/hwclock --systohc >/dev/null 2>&1 0<&1
}
@@ -25,7 +25,7 @@
( spin_lock "${NTPD_LOCK}";
trap 'release_lock "${NTPD_LOCK}"' 0
sleep 20;
- restartservice ntpd; ) &
+ restartservice ntp; ) &
return $rc
}
--- End Message ---
--- Begin Message ---
Joerg Sommrey wrote:
> Package: pm-utils
> Version: 1.1.2.4-1
> Severity: normal
>
>
> Due to a typo in /usr/lib/pm-utils/sleep.d/90clock the ntp daemon is not
> restarted at suspend/resume.
First of all, thanks for the patch.
Restarting the ntp daemon has been removed from 90clock in recent pm-utils
releases (so I'm closing this bug). The relevant discussion which lead to this
is from the pm-utils mailing list
2008/11/30 Dan Nicholson <[email protected]>:
> On Sun, Nov 30, 2008 at 10:54 AM, Victor Lowther
> <[email protected]> wrote:
>> On Nov 30, 2008, at 10:42 AM, "Dan Nicholson" <[email protected]> wrote:
>>>
>>> Yeah, go ahead and release. More releases can always be made later.
>>> What would it take to find if 50ntpd can be removed? I personally
>>> think it's a waste of time, but maybe I'm missing the real reason for
>>> it's existence. Should I ask on the ntp list?
>>
>> Well, this code also seems to go all the way back to the initial checkin,
>> and based on the commit log comments it is there to try and fix any clock
>> drift the system may have experienced while asleep.
>>
>> If we had a way to just tell ntpd to sync at the next oppourtunity, this
>> hook would be much less ugly. However, it seems that there is no such way,
>> so restarting ntpd is the only option, aside from just letting sync
>> according to its usual schedule.
>
> If we assume that the clock has only drifted, and that it's not
> completely out of sync, then I think it would be preferable to just
> let ntpd sync on its own. According to ntp.conf, the default minimum
> polling interval is 64 seconds. So, most likely you'd go 1 minute with
> your clock drifted. I think that's acceptable. You can see what the
> polling interval for your servers is with `ntpdc -c peers'. It would
> be cool if ntpd polled immediately when the network came up, but I
> don't know if it does that.
>
>> Since we don't, it may be best to drop this hook, just let ntpd continue to
>> sync according to its internal schedule, and consider getting networkmanager
>> to kick ntpd for us whenever the internet is back up.
>
> I think ultimately that this can only be handled correctly by the
> system's networking subsystem since it actually knows when the network
> is coming and going. For the common case of NM, it's a trivial
> dispatcher script. That assumes that manually restarting ntpd is
> necessary.
>
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
--- End Message ---
