I have installed Bacula 7.4.4 on an openSUSE Leap 42.3 System from the repository https://build.opensuse.org/package/show/home%3AXimi1970%3AopenSUSE%3AExtra/bacula recommended on https://software.opensuse.org/package/bacula. Those packages use openSUSE's alternatives mechanism to configure the DMBS to use for the catalog - in my case, MySQL. Unfortunately, the package is a bit buggy. After installation of the bacula-director and bacula-mysql packages, the symlinks for the libbaccats library in /usr/lib64 look like this:

libbaccats.so -> /etc/alternatives/libbaccats.so
libbaccats-mysql.so -> libbaccats-mysql-7.4.4.so
libbaccats-stub.so -> libbaccats-7.4.4.so
libbaccats-7.4.4.so -> libbaccats-stub-7.4.4.so

The last two are obviously nonsense and cause any attempts to run the director or the dbcheck utility to fail with the error message:

Fatal error: Please replace this null libbaccats library with a proper one.

This is of course easily fixed by issuing the commands:

ln -sf libbaccats-stub-7.4.4.so libbaccats-stub.so
ln -sf /etc/alternatives/libbaccats-7.4.4.so libbaccats-7.4.4.so

to produce the desired result:

libbaccats.so -> /etc/alternatives/libbaccats.so
libbaccats-7.4.4.so -> /etc/alternatives/libbaccats-7.4.4.so
libbaccats-mysql.so -> libbaccats-mysql-7.4.4.so
libbaccats-stub.so -> libbaccats-stub-7.4.4.so

which allows the symlinks in /etc/alternatives:

libbaccats.so -> /usr/lib64/libbaccats-mysql.so
libbaccats-7.4.4.so -> /usr/lib64/libbaccats-mysql-7.4.4.so

to correctly direct libbaccats references to the MySQL variant.

However, each time the ldconfig(8) command is run it resets the /usr/lib64/libbaccats-7.4.4.so symlink to point to libbaccats-stub-7.4.4.so again, breaking Bacula. Since ldconfig is run automatically by the system on various occasions this is pretty annoying.

The same problem exists with Bacula 9.0.6 from the repository https://download.opensuse.org/repositories/home:/cristyde/openSUSE_Leap_42.3/.

How can I fix ldconfig's idea where that symlink should point?

  • Did you try to symlink the files into /usr/local/lib64? That palce is intended for doing stuff without affecting the standard paths and should be skipped by ldconfig. – Thomas Dec 24 '17 at 15:52
  • No, I didn't try anything involving /usr/local. What exactly do you propose? Which symlinks should I place in /usr/local/lib64? Should I remove any or all of the symlinks in /usr/lib64? – Tilman Schmidt Dec 25 '17 at 0:10

According to my research, the (mis-)behaviour of ldconfig is triggered by the content of the file libbaccats-stub-9.0.6.so, specifically its SONAME field:

ts@xenon:~> objdump -p /usr/lib64/libbaccats-stub-9.0.6.so

/usr/lib64/libbaccats-stub-9.0.6.so:     file format elf64-x86-64
Dynamic Section:
  NEEDED               libc.so.6
  SONAME               libbaccats-9.0.6.so

Apparently that header tells ldconfig to create a symlink with that name.

Proof: If I rename libbaccats-stub-9.0.6.so to libbaccats-stub-9.0.6.so.BAD then ldconfig duly creates a symlink

libbaccats-7.4.4.so -> libbaccats-stub-7.4.4.so.BAD

and if I compress libbaccats-stub-9.0.6.so with gzip instead then ldconfig complains

ldconfig: /usr/lib64/libbaccats-stub-9.0.6.so.gz is not an ELF file - it has the wrong magic bytes at the start.

and leaves my libbaccats-7.4.4.so symlink alone.

So while I haven't found a way to make ldconfig create the correct symlink, there's at least a way to prevent it from recreating the wrong one: delete, compress or otherwise mangle the file /usr/lib64/libbaccats-stub-9.0.6.so.

Of course the real solution would be to set the SONAME field in libbaccats-stub-9.0.6.so correctly, but that would have to happen in the build process of the bacula-director package.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.