Menu
▾
▴
[Bacula-bugs] [bacula 0000038]: bacula-dir does not attempt to connect to database multiple times on startup
|
From: <no...@bu...> - 2004-06-29 16:03:57
|
The following bug has been REOPENED. ====================================================================== http://bugs.bacula.org/bug_view_advanced_page.php?bug_id=0000038 ====================================================================== Reported By: jodym Assigned To: ====================================================================== Project: bacula Bug ID: 38 Category: Director Reproducibility: random Severity: block Priority: normal Status: feedback ====================================================================== Date Submitted: 22-06-2004 13:26 PDT Last Modified: 29-06-2004 09:03 PDT ====================================================================== Summary: bacula-dir does not attempt to connect to database multiple times on startup Description: When the Director starts up, it attempts to connect to the database (one attempt per configured job). If the database is not available--if, for example, the database is also in the process of coming up--the director does not reattempt to connect. A more robust implementation would be to have the Director pause for a short while (10 to 20 seconds...possibly configurable by the user...) and make multiple (two or three) attempts to connect to the database before giving up. This issue is mostly caused by the init script which ships with MySQL. This script invokes the MySQL database program as a background process--and thus exits immediately. If the Bacula init scripts are executed shortly afterward, there is a good chance that MySQL has not finished initializing when the Director attempts to connect to it. ====================================================================== ---------------------------------------------------------------------- Dan Langille - 22-06-2004 16:55 PDT ---------------------------------------------------------------------- FWIW, on FreeBSD, the startup scripts are executed in alphabetical order. I rename the apache and bacula scripts to z-apache.sh and z-bacula.sh to control startup order. ---------------------------------------------------------------------- jodym - 23-06-2004 07:04 PDT ---------------------------------------------------------------------- Thanks for the note, Dan. On Solaris, init scripts are also started in alphabetical order, but the format is a bit different. Start scripts have the format S<##><program name>, e.g. S99bacula-dir; kill scripts have the format K<##><program name>, e.g. K01bacula-dir. The bacula scripts are installed with the S99 prefix, so they are always among the very last start scripts executed. I've always set the MySQL start script to run before the Bacula scripts, and I've experimented with moving it earlier and earlier to put more start scripts between it and Bacula (e.g. S80mysql, S70mysql, S40mysql), but to no avail. Running the MySQL start script before Bacula's doesn't seem to help much, given that the MySQL script launches the database as a background process and exits immediately. The database is still percolating when the Bacula-dir is trying to start. Cheers! Jody ---------------------------------------------------------------------- kern - 29-06-2004 02:55 PDT ---------------------------------------------------------------------- I've attached two patches to this bug report. One for MySQL and one for PostgreSQL. The instructions for applying them are at the top of each file. With the patch applied, Bacula will wait 5 seconds on a failure to connect for up to 6 times (i.e. a total of 30 seconds). The patches apply to version 1.34.5, but probably any 1.34 version. Fixed in version 1.35.0 ---------------------------------------------------------------------- jodym - 29-06-2004 09:03 PDT ---------------------------------------------------------------------- Hi Kern, The mysql.c file does not compile after the mysql.patch file has been applied. I believe that there is a syntax error in mysql.patch: for (int return=0; retry < 6; retry++) { The "return=0" should be "retry=0". Things compiled fine after the syntax error was corrected. I looked at the postgresql.patch file, and I believe that it's okay. Best regards, Jody Bug History Date Modified Username Field Change ====================================================================== 22-06-04 13:26 jodym New Bug 22-06-04 16:55 Dan Langille Bugnote Added: 0000070 23-06-04 07:04 jodym Bugnote Added: 0000074 29-06-04 02:52 kern File Added: mysql.patch 29-06-04 02:53 kern File Added: postgre.patch 29-06-04 02:55 kern Bugnote Added: 0000093 29-06-04 02:55 kern Resolution open => fixed 29-06-04 02:55 kern Status new => closed 29-06-04 09:03 jodym Bugnote Added: 0000095 29-06-04 09:03 jodym Resolution fixed => reopened 29-06-04 09:03 jodym Status closed => feedback ====================================================================== |