Debian Bug report logs - #474500
uptimed: /var/spool/uptimed/records deleted after power fail

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Peter Walser <peterwalser@yahoo.com>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: uptimed: /var/spool/uptimed/records deleted after power fail

Date: Sun, 06 Apr 2008 10:36:27 +0200

Package: uptimed
Version: 1:0.3.10-3
Severity: normal


After more than 200 days running, the server power was shut off.
No big problem. After booting /var/spool/uptimed/records was gone
(or overwritten) and only the current boot is now visible.
Is the file opened at start and closed on normal shutdown
(whith start-stop-daemon)? 

I suggest to open the file, write whatever and close immedately every time.

Suggested cronjob workaround (not tested):
@daily	/etc/init.d/uptimed restart

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (950, 'stable'), (200, 'proposed-updates'), (200, 'stable'), (50, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-6-686
Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8)

Versions of packages uptimed depends on:
ii  debconf [debconf-2.0]  1.5.11etch1       Debian configuration management sy
ii  libc6                  2.3.6.ds1-13etch5 GNU C Library: Shared libraries
ii  libuptimed0            1:0.3.10-3        Library for uptimed

uptimed recommends no packages.

-- debconf information:
  uptimed/mail/do_mail: Never
  uptimed/mail/address: root@localhost
  uptimed/mail/milestones_info:
  uptimed/maxrecords: 50
  uptimed/interval: 60

Message #10 received at 474500@bugs.debian.org (full text, mbox, reply):

From: "Thibaut VARENE" <varenet@debian.org>

To: "Peter Walser" <peterwalser@yahoo.com>, 474500@bugs.debian.org

Subject: Re: Bug#474500: uptimed: /var/spool/uptimed/records deleted after power fail

Date: Sun, 6 Apr 2008 12:27:11 +0200

tags 474500 moreinfo unreproducible
thanks

On Sun, Apr 6, 2008 at 10:36 AM, Peter Walser <peterwalser@yahoo.com> wrote:
> Package: uptimed
>  Version: 1:0.3.10-3
>  Severity: normal
>
>
>  After more than 200 days running, the server power was shut off.
>  No big problem. After booting /var/spool/uptimed/records was gone
>  (or overwritten) and only the current boot is now visible.
>  Is the file opened at start and closed on normal shutdown
>  (whith start-stop-daemon)?

No. The records file is only open when necessary. The daemon doesn't
write directly to that file either. It writes to a temporary file and
then moves it in place of the old records file. I don't see how that
could lead to file corruption unless you've been unlucky enough to
kill power exactly at the moment of the update... Which leads me to
think that the default update interval of 60s is probably overkill and
prone to that kind of situation...

>  I suggest to open the file, write whatever and close immedately every time.

Which is exactly what is done, afaik.

>  Suggested cronjob workaround (not tested):
>  @daily  /etc/init.d/uptimed restart

How's that suppose to help?

Out of curiosity, what filesystem are you using on your system? In
particular what file system is used on /var/spool/uptimed ?

Message #17 received at 474500@bugs.debian.org (full text, mbox, reply):

From: Peter Walser <peterwalser@yahoo.com>

To: 474500@bugs.debian.org

Subject: Re: Bug#474500: uptimed: /var/spool/uptimed/records deleted after power fail

Date: Sun, 6 Apr 2008 19:20:15 +0200

Hallo Thibaut

Thanx for the fast answer.

> >  Is the file opened at start and closed on normal shutdown
> >  (whith start-stop-daemon)?

> No. The records file is only open when necessary. The daemon doesn't
> write directly to that file either. It writes to a temporary file and
> then moves it in place of the old records file. I don't see how that

> think that the default update interval of 60s is probably overkill and
> prone to that kind of situation...

Temporary write and move, then this must be the problem (what else?).

> >  I suggest to open the file, write whatever and close immedately
> >  every time. 

> Which is exactly what is done, afaik.

> >  Suggested cronjob workaround (not tested):
> >  @daily  /etc/init.d/uptimed restart

> How's that suppose to help?

All files are closed and opended again (but that isn't the way the 
program works, you say).

I tried to kill -9 the job several times, but the error was not 
reproducable (random 1 returns 0..9 randomly):
# while true; do sleep $((55 + $(random 1) )); kill -9 $(ps aux | 
grep -v grep | grep uptim | tr -s ' ' | cut -d' ' -f2); sleep 
3; /etc/init.d/uptimed start; cat /var/spool/uptimed/records; done

> Out of curiosity, what filesystem are you using on your system? In
> particular what file system is used on /var/spool/uptimed ?

From /etc/fstab:
/dev/hda8       /var            xfs     defaults        0       2

From <http://en.wikipedia.org/wiki/XFS>:
> Journaling is an approach to guaranteeing file system consistency even
> in presence of power failures or system crashes. XFS provides
> journaling for file system metadata, where file system updates are
> first written to a serial journal before the actual disk blocks are
> updated.    
> ....
> Where recently modified data has not been flushed to disk before a 
> system crash, XFS ensures that any unwritten data blocks are zeroed on 
> reboot, .... XFS's journaling procedures are similar to
> the "writeback" level of ext3.  

The part "unwritten data blocks are zeroed" could be the problem. What 
do you think?

I will set the update interval to 600s and pray ;-)

cu

Peter

Message #22 received at 474500-done@bugs.debian.org (full text, mbox, reply):

From: "Thibaut VARENE" <varenet@debian.org>

To: "Peter Walser" <peterwalser@yahoo.com>, 474500-done@bugs.debian.org

Subject: Re: Bug#474500: uptimed: /var/spool/uptimed/records deleted after power fail

Date: Sun, 6 Apr 2008 20:33:29 +0200

On Sun, Apr 6, 2008 at 7:20 PM, Peter Walser <peterwalser@yahoo.com> wrote:
> Hallo Thibaut

Hi,

>  > think that the default update interval of 60s is probably overkill and
>  > prone to that kind of situation...
>
>  Temporary write and move, then this must be the problem (what else?).

What else? How about this:

>  From /etc/fstab:
>  /dev/hda8       /var            xfs     defaults        0       2

XFS has all sorts of very nice "features" regarding data consistency
and power failure recovery...

>  From <http://en.wikipedia.org/wiki/XFS>:
>  > Journaling is an approach to guaranteeing file system consistency even
>  > in presence of power failures or system crashes. XFS provides
>  > journaling for file system metadata, where file system updates are
>  > first written to a serial journal before the actual disk blocks are
>  > updated.
>  > ....
>  > Where recently modified data has not been flushed to disk before a
>  > system crash, XFS ensures that any unwritten data blocks are zeroed on
>  > reboot, .... XFS's journaling procedures are similar to
>  > the "writeback" level of ext3.
>
>  The part "unwritten data blocks are zeroed" could be the problem. What
>  do you think?

I think I use XFS a lot and would never use it for something such as
/var. I think XFS is probably the reason why you saw this weird bug
and why you cannot reproduce it by killing the daemon, because the
daemon is not at fault.

I'm therefore closing this bugreport and wish you luck ;)

Greetings

T-Bone

-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/

Send a report that this bug log contains spam.