Home / server / Questions / 889520
Accepted
Tilman Schmidt
Asked: 2017-12-25 04:25:23 +0800 CST

ldconfig creating bad symlink

  • 772

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?

linux

1 Answers

  1. Best Answer

    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.

    • 2