[arch-general] Bizarre Clock Reset 8/1 -> 9/1 after apcupsd shutdown??

Leonid Isaev lisaev at umail.iu.edu
Wed Aug 1 19:31:49 EDT 2012


On Wed, 01 Aug 2012 17:50:45 -0500
"David C. Rankin" <drankinatty at suddenlinkmail.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 08/01/2012 03:42 PM, Leonid Isaev wrote:
> <snip>
> >>
> >> Aug  1 13:20:15 providence apcupsd[3477]: apcupsd shutdown succeeded
> >> Aug  1 13:20:15 providence kernel: [171092.364247] apcupsd[3477]: segfault
> >> at 0 ip 0805c706 sp bfcdfff0 error 4 in apcupsd[8048000+38000]
> > 
> > Does apcupsd routinely segfault?
> > 
> 
> No, the segfault just started on July 30:
> 
> [17:40 providence:/var/log] # grep apcupsd everything.log* | grep segfault
> everything.log:Jul 30 13:48:24 providence kernel: [603728.758431]
> apcupsd[3190]: segfault at 0 ip 0805e0fc sp bfe397c0 error 4 in apcupsd
> (deleted)[8048000+39000] everything.log:Aug  1 13:20:15 providence kernel:
> [171092.364247] apcupsd[3477]: segfault at 0 ip 0805c706 sp bfcdfff0 error 4
> in apcupsd[8048000+38000]
> 
> The only config change I can see in the apcupsd.conf.pacnew is:
> 
> LOCKFILE /var/lock  ->  LOCKFILE /etc/apcupsd
> 
> I can't see that causing a segfault, could it?

I don't think so, no. But since something does, I would look at what has been
updated lately (apcupsd for example).

On a side note... I don't use this application (although I do have an APC UPS
unit) but this entry looks very wrong -- is it a lockfile in /etc? Also, I
quickly skimmed through the initscript in /etc/rc.d/apcupsd, at it also does
few writes to /etc. Unless this is absolutely necessary, such behavior
represents a bug and is in violation of FHS.

> 
> 
> >> Aug  1 13:20:15 providence ntpd[3454]: Listen normally on 6 eth0
> >> 192.168.7.124 UDP 123
> >> Aug  1 13:20:15 providence ntpd[3454]: peers refreshed
> >> Aug  1 13:20:15 providence ntpd[3454]: new interface(s) found: waking up
> >> resolver Aug  1 13:20:15 providence postfix/postfix-script[13735]:
> >> stopping the Postfix mail system
> >> Aug  1 13:20:15 providence postfix/master[3868]: terminating on signal 15
> >> Aug  1 13:20:15 providence postfix/postfix-script[13738]: waiting for the 
> >> Postfix mail system to terminate
> >> Aug  1 13:20:16 providence dhcpcd[424]: eth0: sending IPv6 Router
> >> Solicitation Aug  1 13:20:19 providence ntpd[3454]: ntpd exiting on
> >> signal 15
> > 
> > Your NTP behaves strangely... why would it refresh timeservers and then
> > shutdown at the same timestamp? It looks like your ntp did something funny
> > and incorrectly adjusted the HW clock.
> 
> Now that you mention it, I don't know why it would refresh at shutdown. I
> think this is just a normal log event that occurred between the time the
> apcupsd shutdown was commanded at 13:20:15 and the ntpd refresh at 13:20:15.
> I just don't think ntpd had time to get the message yet...

Well, unless you have hwclock daemon, ntpd is the only thing which affects HW
clock.

> 
> Thanks for your help. I occurred during a power event, so I guess we'll just
> chock it up to stray voltage that somehow zapped the month bit in the bios
> ahead by 1..... Sounds screwy, but I don't know the system/kernel/bios well
> enough to know how else it could have occurred or what even interfaces with
> the hardware clock for that matter. System time was fine up until the time
> of restart...
> 
> - -- 
> David C. Rankin, J.D.,P.E.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.16 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAlAZssUACgkQZMpuZ8CyrcgM6gCfcqf+TsykvukqW/ca0La2l6Tc
> lIYAn1YizdUmq9+lCD0Ns5jEDd02NwXf
> =d3sE
> -----END PGP SIGNATURE-----



-- 
Leonid Isaev
GnuPG key: 0x164B5A6D
Fingerprint: C0DF 20D0 C075 C3F1 E1BE  775A A7AE F6CB 164B 5A6D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://mailman.archlinux.org/pipermail/arch-general/attachments/20120801/42021071/attachment.asc>


More information about the arch-general mailing list