Thomas E. Ruth wrote:
> I havn't been able to automate a restore completely within bacula for
> DB2 databases, but I've gotten close. The bacula restore process
> creates a FIFO with only root permissions but doesn't change the
> permissions of the actual fifo file until data starts restoring to it.
> At that time though, it's too late for the DB2 process (I think the file
> is actually deleted and re-created and the DB2 process loses it's handle
> on it).
After thinking about what's going on here, I think this is a behavioral
error on Bacula's part. I suspect that *by default*, Bacula should
never overwrite a FIFO that already exists during a restore. If it's
not there, fine, restore it; if it's already there, LEAVE IT ALONE, we
don't want to break anything. Write any data to it that's supposed to
be written to it, sure, but if we delete and recreate the FIFO, we may
break things -- as in this example.
This probably applies to socket pseudo-nodes as well, assuming we even
restore those at all (which I still believe we shouldn't).
--
Phil Stracchino [EMAIL PROTECTED]
Renaissance Man, Unix generalist, Perl hacker
Mobile: 603-216-7037 Landline: 603-886-3518
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
