Bug 784587 - Bacula director broken, trys to connect to postgresl when database is mysql
Bacula director broken, trys to connect to postgresl when database is mysql
Product: Fedora
Classification: Fedora
Component: bacula (Show other bugs)
Unspecified Unspecified
unspecified Severity urgent
: ---
: ---
Assigned To: Simone Caronni
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2012-01-25 08:30 EST by Sergio Pascual
Modified: 2012-02-09 19:52 EST (History)
9 users (show)

See Also:
Fixed In Version: bacula-5.0.3-26.fc16
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-02-09 19:49:21 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Installation log (8.98 KB, text/plain)
2012-01-26 03:01 EST, Simone Caronni
no flags Details

  None (edit)
Description Sergio Pascual 2012-01-25 08:30:59 EST
Description of problem:
This is (was) a working bacula instance. Database is mysql. 
When bacula-director starts, it start connecting to a postgresql database instead of to my mysql database, as it did with bacula-5.0.3-11

Version-Release number of selected component (if applicable):
From bacula-5.0.3-19 and up

How reproducible:

Steps to Reproduce:
1. Start bacula director

Actual results:
It's not starting

Messages show that bacula is trying to connect to a postgresql database, although I have only bacula-director-mysql installed

Jan 25 14:07:55 parix bacula-dir[16467]: bacula-dir: dird.c:950 Could not open Catalog "MyCatalog", database "bacula".
Jan 25 14:07:55 parix bacula-dir[16467]: bacula-dir: dird.c:955 postgresql.c:227 Unable to connect to PostgreSQL server. Database=bacula User=bacula
Jan 25 14:07:55 parix bacula-dir[16467]: Possible causes: SQL server not running; password incorrect; max_connections exceeded.

Expected results:
bacula-dir starts and connects

Additional info:
bacula-5.0.3-11 is the last version where bacula works
Comment 1 Paul Howarth 2012-01-25 08:38:42 EST
Try this update:

Comment 2 Simone Caronni 2012-01-25 08:57:12 EST
Yes, it is fixed in that version, sorry for the problem. It is coming as stable in f15/f16. Rawhide does not have the problem.

Part of the enablement of bpipe-fd.so plugin involves using libtool to generate shared objects.

In 5.0.3 this leads to the generation of various libraries among which is libbacsql-5.0.3.so which is dependant on the backend used at configure time, like the director binary.

The symptom is that all variants of the binaries get linked to their correct
library PLUS the PostgreSQL library.

[root@3zpc0560 ~]# ldd /usr/sbin/dbcheck | egrep "pq|sql"
        libbacsql-5.0.3.so => /usr/lib64/libbacsql-5.0.3.so (0x00007f544145b000)
        libsqlite3.so.0 => /usr/lib64/libsqlite3.so.0 (0x00000036dca00000)
        libpq.so.5 => /usr/lib64/libpq.so.5 (0x0000003462c00000)

The funny thing is that any package does NOT require the library, as ldconfig takes into input also the libraries loaded by the executable and also libbacsql-5.0.3.so needs to be versioned in the alternatives system. So checking the packages, all is correct. If you check the single library with ldd you get the problem because it loads also the dependent libraries.

That's the main reason they switched to their new system in 5.2.4.
Comment 3 Gwyn Ciesla 2012-01-25 20:38:34 EST
I needed to manually /sbin/ldconfig for bacula-dir to find libbacsql-5.0.3.so, but then it worked fine.
Comment 4 Simone Caronni 2012-01-26 03:01:01 EST
Created attachment 557599 [details]
Installation log
Comment 5 Simone Caronni 2012-01-26 03:03:19 EST
I don't know, it does not happen on my system, the library link should be created by the alternatives system and not by ldconfig:

[root@3zpc0560 ~]# ls -la /usr/lib64/libbacsql*
lrwxrwxrwx. 1 root root     36 Jan 26 08:50 /usr/lib64/libbacsql-5.0.3.so -> /etc/alternatives/libbacsql-5.0.3.so
-rwxr-xr-x. 1 root root 138896 Jan 25 09:37 /usr/lib64/libbacsql-5.0.3.so.sqlite
lrwxrwxrwx. 1 root root     30 Jan 26 08:50 /usr/lib64/libbacsql.so -> /etc/alternatives/libbacsql.so

I've attached a log file that shows a complete SQLite installation from scratch, I don't have any errors. Can you check that?
Comment 6 Donnie Pennington 2012-01-26 06:56:07 EST
After encountering this bug and then updating bacula, I also had to do ldconfig:

[root@ion-fedora bacula]# systemctl status bacula-dir.service
bacula-dir.service - Bacula-Director, the Backup-server
	  Loaded: loaded (/lib/systemd/system/bacula-dir.service; enabled)
	  Active: failed since Thu, 26 Jan 2012 06:43:59 -0500; 1min 31s ago
	 Process: 13270 ExecStart=/usr/sbin/bacula-dir -f $OPTS -c $CONFIG -u $DIR_USER -g $DIR_GROUP (code=exited, status=127)
	 Process: 13267 ExecStartPre=/usr/sbin/bacula-checkconf $CONFIG (code=exited, status=0/SUCCESS)
	  CGroup: name=systemd:/system/bacula-dir.service
[root@ion-fedora bacula]# /sbin/ldconfig
[root@ion-fedora bacula]# systemctl restart bacula-dir.service
[root@ion-fedora bacula]# systemctl status bacula-dir.service
bacula-dir.service - Bacula-Director, the Backup-server
	  Loaded: loaded (/lib/systemd/system/bacula-dir.service; enabled)
	  Active: active (running) since Thu, 26 Jan 2012 06:46:12 -0500; 9s ago
	 Process: 13306 ExecStartPre=/usr/sbin/bacula-checkconf $CONFIG (code=exited, status=0/SUCCESS)
	Main PID: 13309 (bacula-dir)
	  CGroup: name=systemd:/system/bacula-dir.service
		  └ 13309 /usr/sbin/bacula-dir -f -c /etc/bacula/bacula-dir....
Comment 7 Gwyn Ciesla 2012-01-26 08:10:53 EST
ldconfig updates the linker cache, not the symlink.  Anytime you modify solibs, you need to rerun /sbin/ldconfig.  All solib-bearing RPMS are to do this in %post and %postun.
Comment 8 Sergio Pascual 2012-01-26 10:00:22 EST
Not directly related to this, but it seems that bacula-storage-mysql-5.0.3-22 requires libbacsql.so that in turn brings bacula-director-mysql and bacula-director-common

So I'm ending up with most of the director files installed in my storage server. Is it possible to have libbacsql.so in a shared package bacula-mysql? 

Then bacula-director-mysql and bacula-storage-mysql could depend on it. The same apply to the other backends
Comment 9 Simone Caronni 2012-01-26 10:37:30 EST
Yes, but this is what I wanted to do from the beginning and is applied to the current rawhide builds (5.2.5-1) where we have a simple bacula-libs which is used to select the backend.

I think I need to provide a bit of background:

In 5.0.3, unfortunately, the backend is not only tied to a single library but also to some binaries and the bacula-dir executable. We have a couple of problems in Fedora 15/16:

1) The old package (rev. 11) did not have shared objects enabled (I don't know why) and thus it was not able to support plugins and the binaries were fat.

2) The libbaccsql library is needed by commands which are scattered among bacula directors and storage daemons.

These are specific mysql variants for the director:


These are specific mysql variants for the storage:


And these are specific mysql variant libraries that are needed by both:


Bacula Systems ships separate and distinct packages for their Enterprise Version 4.0 and makes them conflicting with each other. They also package everything into a single package and you activate only the daemons you need. I don't personally like this approach, but at least alleviates you from having to ship alternatives, symlinks with ldconfig problems and cross-package dependencies.

But it's not finished there:

In 5.2.1 they made all the common code into three libbaccats library so you only needed to symlink that to choose the backend, but that meant having a stub library in the main package as the soname of the library was different:


There's no way to tell yum to install a package where you have the library available after running through the %post script; so yum would always fail the dependency check unless you provided a fake library in the package but marked it as %ghost because it would be overwritten by an alternatives managed symlink.

In 5.2.4 they left everything as is, but they changed the internal shared object name so at least the three variants expose always the name libbaccats-5.2.5.so and yum, ldconfig and rpm became happy. 

There was a long discussion by mail with people from Fedora that helped me sorting this out.

The bacula.spec from 5.0.3 is long as hell, with bacula being built 3 times and the only way to overcome this is to put a separate bacula-libs package along with bacula-libs-{mysql,postgresql,sqlite} variants for each. And this way you will have three alternatives set; bacula-director, bacula-storage and bacula-libs.

If that is ok I can proceed in coding this into the spec file.


PS: Here are the actual 5.2.x rawhide packages rebuilt for Fedora 15/16:
Comment 10 Simone Caronni 2012-01-26 11:20:45 EST
I committed the ldconfig change into git.

I'm not the only one not needing to run ldconfig though:
Comment 11 Simone Caronni 2012-01-27 04:33:29 EST

I've splitted the libs in sub-packages; one common and one for each backed type.

You can see the change here:


These are the packages that are built by the spec file:


Variant directors and storage require the bacula-libs-<variant> along with the base bacula-libs package. All run ldconfig in %post and %postun.

The block of lines for %post, %postun, %pre, %preun etc. is a whopping 270 lines of code.

I did test some upgrades, updates, etc. and all seem to work fine.

I triggered a build for f15/f16, can someone test it so that I can push an update to stable if they are working correctly?


Comment 12 Simone Caronni 2012-01-30 07:32:10 EST
Another build, can someone test?


Comment 13 Fedora Update System 2012-01-31 02:53:29 EST
bacula-5.0.3-26.fc16 has been submitted as an update for Fedora 16.
Comment 14 Fedora Update System 2012-01-31 02:54:16 EST
bacula-5.0.3-26.fc15 has been submitted as an update for Fedora 15.
Comment 15 Fedora Update System 2012-01-31 17:00:23 EST
Package bacula-5.0.3-26.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing bacula-5.0.3-26.fc16'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
Comment 16 Simone Caronni 2012-02-09 06:35:08 EST

I heard no negative feedback about the update, so I'm pushing it to stable.

Remember that since now libraries are split into subpackages and all daemons depend just on these, you must install only the libraries you really need.

That is, in the case of a MySQL Storage / Director installation:

yum install bacula-director-mysql bacula-libs-mysql bacula-storage-mysql

In my case, for a SQLite installation with all the daemons on the same machine:

[root@3zpc0560 ~]# rpm -qa bacula\* | sort

Any doubt, feel free to ask.

Comment 17 Fedora Update System 2012-02-09 19:49:21 EST
bacula-5.0.3-26.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 18 Fedora Update System 2012-02-09 19:52:21 EST
bacula-5.0.3-26.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.