Backup Central

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!

pll+amanda < at > permabit.com wrote:

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]
...
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?

Besides the fact that a LOT of programs will fail mysteriously when
/dev/null has been tampered with, here is a patch for sendsize.c .

ps. Ever replaced /dev/null with a plain file by accident? :-)

PPS. patch not tested to verify it it really detects the problem :-)

--
Paul Bijnens, Xplanation Tel +32 16 397.511
Technologielaan 21 bus 2, B-3001 Leuven, BELGIUM Fax +32 16 397.512
http://www.xplanation.com/ email: Paul.Bijnens < at > xplanation.com
***********************************************************************
* I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, F6, *
* quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, *
* stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, *
* PF4, F20, ^X^X, :, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, *
* kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... *
* ... "Are you sure?" ... YES ... Phew ... I'm out *
***********************************************************************


--- sendsize.c_ORIG 2004-06-07 16:08:12.000000000 +0200
+++ sendsize.c 2004-06-07 16:07:04.000000000 +0200
< at > < at > -797,6 +797,9 < at > < at >
rundump_cmd = stralloc(cmd);

stdoutfd = nullfd = open("/dev/null", O_RDWR);
+ if (nullfd < 0) {
+ error("%s: open /dev/null returned: %s", cmd, strerror(errno));
+ }
pipefd[0] = pipefd[1] = killctl[0] = killctl[1] = -1;
pipe(pipefd);

In a message dated: Mon, 07 Jun 2004 16:15:47 +0200
Paul Bijnens said:

Besides the fact that a LOT of programs will fail mysteriously when
/dev/null has been tampered with, here is a patch for sendsize.c .

Thanks!

ps. Ever replaced /dev/null with a plain file by accident? :-)

Mmmmm, can I plead the 5th ? ;)

PPS. patch not tested to verify it it really detects the problem :-)

Thanks for the warning
--
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!

On Mon, Jun 07, 2004 at 04:15:47PM +0200, Paul Bijnens wrote:
+ error("%s: open /dev/null returned: %s", cmd, strerror(errno));

May I suggest a wording change in the message: "failed" instead
of "returned". Besides the nit-picky observation that what was
*returned* was -1, it's better to state explicitly that it was a
failure, rather then leaving the reader to infer it.

--

| | /\
|-_|/ > Eric Siegerman, Toronto, Ont. erics < at > telepres.com
| | /
It must be said that they would have sounded better if the singer
wouldn't throw his fellow band members to the ground and toss the
drum kit around during songs.
- Patrick Lenneau