>... that tells me that it is not partition dependent at least. ...
Agreed. Not sure if that's good or bad :-).
>I am not getting any core files ...
OK.
Please try the following patch. It will not fix anything, but will log
the exit code of all the processes driver starts, in particular, the
messed up dumpers. Actually, it will only log them if they indicate some
kind of failure, but I'd be surprised if they are going away cleanly.
The messages will go to the E-mail report and also to the tail end
of amdump.1. Please post the last 30 or so lines of amdump.1 when you
get the next failure.
My guess at the moment is that dumper got a signal of some type that
caused it to exit. That should show up in the patched output.
Assuming that's what happens, you might also pick one or more of the
"exited with signal NN" lines and look up signal number "NN" in your
/usr/include/sys/signal.h file and let me know what they are, just to
make sure we don't start talking about apples and oranges because of
OS differences.
>... If you go to the end of the file at the point where it starts
>doing the first of the backups that failed, for some reason it starts
>backing directly to tape. ...
Huh? I don't see that in the log you sent. All the commands I see
are FILE-DUMP. Which file are you talking about (what "start at" from
the first line)? Or what makes you think it was direct to tape?
In any case, it doesn't really matter. All the other failures I've seen
in your logs are through the holding disk, so even if this one was direct
to tape, that does not seem to be related.
> markh
John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
(Run "e mhn" at "What now?", then $}base64 -d as needed and remove the
Content-Transfer-Encoding line (leave it blank) and these lines.)
driver.diff
