On Saturday 23 July 2005 20:50, Phil Stracchino wrote:
> OK, I have the beginnings of a clue here. First of all, when I
> restarted bacula with debugging enabled (at -d200) on the sd, the sd
> reported 3 jobs on the volume and 1 on the catalog, and errored out the
> tape. I loaded a fresh tape, ran the failing job again, and didn't get
> any clues. So I stopped bacula, turned debug on the sd up to 400, and
> restarted. Again, the volume was errored. I purged it, remounted, and
> reran.
>
> Nothing obviously interesting is showing up in the sd debug output, but
> what's interesting is that this time, after the job failed, I tried to
> unmount the tape to see if that would prevent it being errored out.
> However, I couldn't unmount it:
>
>
>
> unmount
> Automatically selected Storage: VXA1
> 3905 Device /dev/nst0 is busy with 2 writer(s).
> status dir
> babylon5-dir Version: 1.36.3 (22 April 2005) i686-pc-linux-gnu slackware
> 7.0.0
> Daemon started 23-Jul-05 14:27, 2 Jobs run since started.
>
> Scheduled Jobs:
> Level Type Pri Scheduled Name Volume
> ===========================================================================
>======== Incremental Backup 10 23-Jul-05 21:30 Mabolgamp Save
> VXA-V17-Full-0007
> Incremental Backup 10 24-Jul-05 02:15 Babylon5 Save
> VXA-V17-Full-0007
> Incremental Backup 10 24-Jul-05 02:15 Minbar Save
> VXA-V17-Full-0007
> Incremental Backup 10 24-Jul-05 02:15 Llioness Save
> VXA-V17-Full-0007
> Differential Backup 15 24-Jul-05 03:45 Catalog Save
> VXA-V17-Full-0007
> ====
>
> Running Jobs:
> No Jobs running.
> ====
>
>
> The director says nothing's running, but the sd seems to think two
> processes (or threads?) are still trying to write to the drive.
>
>
> I've attached the log, but I don't see anything immediately enlightening
> in it. Should I try an even higher debug level? And if it's an sd
> problem, why would it be consistently affecting this client, but no
> others...?
Well, without knowing the client names, and the JobIds of the jobs you
started, it is very difficult to understand debug output. The only thing
that I see is that the SD forceably closed a connection that was hanging on a
read() with a FD when you killed the SD.
Sorry, but in any such debug output, labeling, mounting, unmounting, running
multiple jobs only complicates and obscures the problem.
You might make sure you have the latest drivers/firmware for the ethernet card
in your Windows system that is giving you problems. At least one user
recently found that this was the cause of his disconnects with a Windows
machine -- he had a NVidia ethernet card.
--
Best regards,
Kern
(">
/\
V_V
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
