I restarted the sd demon, and it solved the problem. A few questions appear below.
On Wed, Jun 22, 2005 at 09:41:38PM +0200, Arno Lehmann wrote: > Hi, > > Ross Boylan wrote: > > >As detailed in my earlier messages, I have my storage writing to disk > >files, and my first attempt failed because I had an invalid volume > >name. > > > >I have cancelled the offending jobs (except parts linger on--see > >later), fixed (maybe) my label generation, and asked the director to > >reload its configuration (I'm not sure if that's a full restart under > >the hood or not--this is on Debian). > > One important question: Is anything vital running in bacula at the > moment? The most effective way to to get everything unstuck is, after > all, a /etc/init.d/bacula restart or killall -9 bacula :-) No. I'm still at the experimental phase. Speaking of which, when I finally stop mucking around, what's the best way to cleanup. I see "delete" and "purge" commands. It's hard to tell what the difference is. Perhaps delete on a volume just deletes the volume, while purge clears the related file and job entries too? I take it I also need to delete the actual files (the "volumes" on my disk) to get rid of them. I believe the standard advice is to rerun the database creation scripts, but they are tied into the Debian package installation procedures, so I'm reluctant to go that route. > > On the clients with stuck fd too, of course... > > Usually, a reload (or reload from inside a console) is not a restart > but This is the second answer that refers to reload from the console, but I don't see any such command in the manual. Am I missing something? What I meant was a did the Debian-specific /etc/init.d/bacula-dir force-reload which I assume is sending a signal to the process. To restart the sd I did /etc/init.d/bacula-sd restart > only triggers reloading of the configuration (this works in the director > only!). Usually, the reload will be queued, because (my personal guess > without any real knowledge about the source) it might change important > data in running or queued jobs. Hadn't thought of that.... I also hope that randomly restarting particular demons won't screw up the other ones. ... > >I do not want to use label from the console, because it is the > >automatic labelling that I need to test (I also don't know if that > >would help things). > > Understandable. Still, why not simply shutdown bacula and restart it? I did. Out of curiosity, does anyone know if doing a manual label would have got the storage demon going? > > The stuck jobs on remote machines will usually time out after 2 hours. > If they don't it should be safe to restart their daemons. All on one machine before I try anything fancy :) > > Concerning a stuck SD - that's tricky. I managed that myself some times, > but it always involved tape devices here. In those cases, there was > either a really long timeout necessary (long in computer terms - we're > talking about some hours here) or I turned the drive's power off, waited > for the kernel to start complaining, turned it on again. After that, the > SD recovered quickly. Even though I tried some of the tape-oriented commands (unmount, release) this was just a wild guess. I don't know what, if anything, they do with file backup. Anybody know? ------------------------------------------------------- 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