Amanda-Users

/dev/null caused backups to fail

2004-06-07 09:46:50
Subject: /dev/null caused backups to fail
From: pll+amanda AT permabit DOT com
To: amanda-users AT amanda DOT org
Date: Mon, 07 Jun 2004 09:41:46 -0400
All file systems on one of my backup clients failed over the weekend. 
The dump summary thinks the system was offline, but it wasn't, and 
the amadad debug log had this in it:

amandad: time 0.016: amandahosts security check passed
amandad: time 0.016: running service "/usr/lib/amanda/sendsize"
sendsize: error [spawn /usr/lib/amanda/runtar: dup2 in: Bad file descriptor]
sendsize: error [spawn /usr/lib/amanda/runtar: dup2 in: Bad file descriptor]
sendsize: error [spawn /usr/lib/amanda/runtar: dup2 in: Bad file descriptor]
sendsize: error [spawn /usr/lib/amanda/runtar: dup2 in: Bad file descriptor]
sendsize: error [spawn /usr/lib/amanda/runtar: dup2 in: Bad file descriptor]
sendsize: error [spawn /usr/lib/amanda/runtar: dup2 in: Bad file descriptor]
sendsize: error [spawn /usr/lib/amanda/runtar: dup2 in: Bad file descriptor]
sendsize: error [spawn /usr/lib/amanda/runtar: dup2 in: Bad file descriptor]
amandad: time 0.566: sending REP packet:

The sendsize debug log also reveals:

# grep 'no size line' sendsize.20040605234503.debug
sendsize[30741]: no size line match in /bin/tar output for "/u1/backup/all"
sendsize[30742]: no size line match in /bin/tar output for "/u1/backup/aog"
sendsize[30745]: no size line match in /bin/tar output for "/u1/backup/archive"
sendsize[30747]: no size line match in /bin/tar output for "/u1/backup/bfb"
sendsize[30749]: no size line match in /bin/tar output for 
"/u1/backup/cvs-repos"
sendsize[30751]: no size line match in /bin/tar output for "/u1/backup/pd"
sendsize[30753]: no size line match in /bin/tar output for "/u1/backup/rt"
sendsize[30755]: no size line match in /bin/tar output for "/u1/backup/sw"

After digging through all this, I tried seeing what amcheck revealed 
(which I should have done first :)  It stated:

 ERROR: jpt: [can not read/write /dev/null: Permission denied]

Evidently, from what I can tell, /dev/null's permissions were changed 
sometime  on Friday (16:42 to be precise) after my cron-driven amcheck runs.

Is there any way to have amanda mention in the summary report that 
the reason a backup failed was because /dev/null was not writeable?


Thanks,

-- 
Seeya,
Paul

GPG Key fingerprint = 1660 FECC 5D21 D286 F853  E808 BB07 9239 53F1 28EE

         If you're not having fun, you're not doing it right!



<Prev in Thread] Current Thread [Next in Thread>