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: Always 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
Try this update: https://admin.fedoraproject.org/updates/bacula-5.0.3-22.fc16
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.
I needed to manually /sbin/ldconfig for bacula-dir to find libbacsql-5.0.3.so, but then it worked fine.
Created attachment 557599 [details] Installation log
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?
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....
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.
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
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: %{_sbindir}/bacula-dir.mysql %{_sbindir}/dbcheck.mysql %{_libexecdir}/bacula/create_mysql_database %{_libexecdir}/bacula/drop_mysql_database %{_libexecdir}/bacula/drop_mysql_tables %{_libexecdir}/bacula/grant_mysql_privileges %{_libexecdir}/bacula/make_mysql_tables %{_libexecdir}/bacula/update_mysql_tables %{_libexecdir}/bacula/create_bacula_database.mysql %{_libexecdir}/bacula/drop_bacula_database.mysql %{_libexecdir}/bacula/drop_bacula_tables.mysql %{_libexecdir}/bacula/grant_bacula_privileges.mysql %{_libexecdir}/bacula/make_bacula_tables.mysql %{_libexecdir}/bacula/make_catalog_backup.mysql %{_libexecdir}/bacula/update_bacula_tables.mysql %{_libexecdir}/bacula/bacula_config.mysql These are specific mysql variants for the storage: %{_sbindir}/bcopy.mysql %{_sbindir}/bscan.mysql %{_sbindir}/btape.mysql And these are specific mysql variant libraries that are needed by both: %{_libdir}/libbacsql-%{version}.so.mysql 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: libbaccats-mysql-5.2.5.so libbaccats-sqlite3-5.2.5.so libbaccats-postgresql-5.2.5.so 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. --Simone PS: Here are the actual 5.2.x rawhide packages rebuilt for Fedora 15/16: http://repos.fedorapeople.org/repos/slaanesh/bacula/README.txt
I committed the ldconfig change into git. I'm not the only one not needing to run ldconfig though: https://bugzilla.redhat.com/show_bug.cgi?id=784868
Hello, I've splitted the libs in sub-packages; one common and one for each backed type. You can see the change here: http://pkgs.fedoraproject.org/gitweb/?p=bacula.git;a=commitdiff;h=565c5c6af6936bf0e401c0604e92935627588fc7 These are the packages that are built by the spec file: bacula-5.0.3-24.fc16.src.rpm bacula-client-5.0.3-24.fc16.x86_64.rpm bacula-common-5.0.3-24.fc16.x86_64.rpm bacula-console-5.0.3-24.fc16.x86_64.rpm bacula-console-bat-5.0.3-24.fc16.x86_64.rpm bacula-console-wxwidgets-5.0.3-24.fc16.x86_64.rpm bacula-debuginfo-5.0.3-24.fc16.x86_64.rpm bacula-devel-5.0.3-24.fc16.x86_64.rpm bacula-director-common-5.0.3-24.fc16.x86_64.rpm bacula-director-mysql-5.0.3-24.fc16.x86_64.rpm bacula-director-postgresql-5.0.3-24.fc16.x86_64.rpm bacula-director-sqlite-5.0.3-24.fc16.x86_64.rpm bacula-libs-5.0.3-24.fc16.x86_64.rpm bacula-libs-mysql-5.0.3-24.fc16.x86_64.rpm bacula-libs-postgresql-5.0.3-24.fc16.x86_64.rpm bacula-libs-sqlite-5.0.3-24.fc16.x86_64.rpm bacula-storage-common-5.0.3-24.fc16.x86_64.rpm bacula-storage-mysql-5.0.3-24.fc16.x86_64.rpm bacula-storage-postgresql-5.0.3-24.fc16.x86_64.rpm bacula-storage-sqlite-5.0.3-24.fc16.x86_64.rpm bacula-traymonitor-5.0.3-24.fc16.x86_64.rpm nagios-plugins-bacula-5.0.3-24.fc16.x86_64.rpm 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? http://koji.fedoraproject.org/koji/buildinfo?buildID=295988 http://koji.fedoraproject.org/koji/buildinfo?buildID=295989 Thanks, --Simone
Another build, can someone test? http://koji.fedoraproject.org/koji/buildinfo?buildID=296292 http://koji.fedoraproject.org/koji/buildinfo?buildID=296293 Thanks, --Simone
bacula-5.0.3-26.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/bacula-5.0.3-26.fc16
bacula-5.0.3-26.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/bacula-5.0.3-26.fc15
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: https://admin.fedoraproject.org/updates/FEDORA-2012-1072/bacula-5.0.3-26.fc16 then log in and leave karma (feedback).
Hello, 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 bacula-client-5.0.3-26.fc16.x86_64 bacula-common-5.0.3-26.fc16.x86_64 bacula-console-5.0.3-26.fc16.x86_64 bacula-console-bat-5.0.3-26.fc16.x86_64 bacula-director-common-5.0.3-26.fc16.x86_64 bacula-director-sqlite-5.0.3-26.fc16.x86_64 bacula-libs-5.0.3-26.fc16.x86_64 bacula-libs-sqlite-5.0.3-26.fc16.x86_64 bacula-storage-common-5.0.3-26.fc16.x86_64 bacula-storage-sqlite-5.0.3-26.fc16.x86_64 Any doubt, feel free to ask. Regards, --Simone
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.
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.