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

2008-04-06 Thread Peter Walser
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  libuptimed01:0.3.10-3Library for uptimed

uptimed recommends no packages.

-- debconf information:
  uptimed/mail/do_mail: Never
  uptimed/mail/address: [EMAIL PROTECTED]
  uptimed/mail/milestones_info:
  uptimed/maxrecords: 50
  uptimed/interval: 60



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



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

2008-04-06 Thread Thibaut VARENE
tags 474500 moreinfo unreproducible
thanks

On Sun, Apr 6, 2008 at 10:36 AM, Peter Walser [EMAIL PROTECTED] 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 ?



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



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

2008-04-06 Thread Peter Walser
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   /varxfs defaults0   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