Menu
▾
▴
[Bacula-bugs] [bacula 0000780]: Win2003: Client cannot connect to storage daemon after running a very long "clientrunbefore" job
|
From: <bac...@li...> - 2007-02-28 13:29:18
|
The following issue requires your FEEDBACK. ====================================================================== http://bugs.bacula.org/view.php?id=780 ====================================================================== Reported By: mdevogelaere Assigned To: ====================================================================== Project: bacula Issue ID: 780 Category: Storage Daemon Reproducibility: always Severity: block Priority: normal Status: feedback ====================================================================== Date Submitted: 02-12-2007 07:41 EST Last Modified: 02-28-2007 08:29 EST ====================================================================== Summary: Win2003: Client cannot connect to storage daemon after running a very long "clientrunbefore" job Description: Client: Windows 2003-server. Storage-daemon: RHEL4-server. Director: RHEL4-server. A windows2003-server runs a long "clientrunbefore" job. That job takes about 1.5 hours. After that the windows2003-server should connect to the storage-daemon and start spooling data. That does not happen with bacula storage-daemon 2.0.0/2.0.1/2.0.2 on the linux-server However if works fine with bacula 1.39.28 on the storage-daemon. So i suspect the issue is related to the storage-daemon. The version of bacula on the windows2003-server does not seem to be relevant: identical behaviour occurs with 1.39.28/2.0.0/2.0.1/2.0.2. ====================================================================== ---------------------------------------------------------------------- mdevogelaere - 02-12-07 10:35 ---------------------------------------------------------------------- Both computers are on the same network: there is no router between them. ---------------------------------------------------------------------- kern - 02-15-07 10:12 ---------------------------------------------------------------------- We are looking at a fix for this. In the mean time, I suggest you use a 1.38.11 client (or possibly the 1.39.28 client). You may have no choice, but having a ClientRunBeforeJob that takes more than 30 minutes (IMO) is not a very good idea -- with network connections open, it just invites problems and has possibly blocked critical SD resources from being used during that time. ---------------------------------------------------------------------- mdevogelaere - 02-19-07 03:33 ---------------------------------------------------------------------- Thanks for looking into this ! That job is dumping the mssql-databases: it needs to be executed prior to executing the backup. I could run the same job through the task scheduler but then i'm not completely sure the job is completed when the backup starts. So that's not an option to me. And a similar problem might occur when dumping the database of bacula itself: my postgresql-server now needs about 42 minutes to produce the dump and that exceeds the proposed 30 minutes also. I'm not worried too much about the SD resources. My jobs run concurrently and the other backupjobs run during several hours: it doesn't really matter to me that the preparation takes about 1.5 hours since the SD is active with other jobs during that 1.5 hours. It's now running stable with a 2.0.2 client and a 1.39.28 SD/DIR. ---------------------------------------------------------------------- kern - 02-28-07 08:29 ---------------------------------------------------------------------- This bug should be fixed with the two attached files. Please test by downloading fd_cmds.c and putting it into your <bacula-source>/src/dird directory, and jobs.c goes into your <bacula-source>/src/filed directory. Then do: cd <bacula-source> make ... make install Note, both the Director and the File daemon will be updated. I would appreciate to know if this resolves your problem. If you need a Win32 client, I can supply one. Issue History Date Modified Username Field Change ====================================================================== 02-12-07 07:41 mdevogelaere New Issue 02-12-07 10:35 mdevogelaere Note Added: 0002220 02-12-07 10:36 mdevogelaere Issue Monitored: mdevogelaere 02-15-07 10:12 kern Note Added: 0002230 02-15-07 10:12 kern Status new => acknowledged 02-19-07 03:33 mdevogelaere Note Added: 0002238 02-28-07 08:25 kern File Added: fd_cmds.c 02-28-07 08:26 kern File Added: job.c 02-28-07 08:29 kern Note Added: 0002268 02-28-07 08:29 kern Status acknowledged => feedback ====================================================================== |