Commons Daemon
  1. Commons Daemon
  2. DAEMON-246

jsvc fails to load libcap.so.2 from /lib64

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.0.10
    • Fix Version/s: 1.0.11
    • Component/s: Jsvc
    • Labels:
      None
    • Environment:

      Fedora Core 16 (x86_64, using an x86_64 jsvc), CentOS 5.5 (x86_86, using an x86_64 jsvc), Debian Squeeze (x86_64, using an i686 jsvc), Debian Wheezy (x86_64, using an i686 jsvc)

      Description

      I see this when running jsvc -debug ...

      Attemtping to load library /lib/libcap.so.2
      Attemtping to load library /lib/libcap.so.1
      Attemtping to load library /lib/libcap.so
      Attemtping to load library /usr/lib/libcap.so.2
      Attemtping to load library /usr/lib/libcap.so.1
      Attemtping to load library /usr/lib/libcap.so
      failed loading capabilities library – /usr/lib/libcap.so: cannot open shared
      object file: No such file or directory.

      This does not work on 64bit Fedora, as the lib directory is /lib64/.

      It also won't work if you're using a 32bit copy of jsvc on a 64bit copy of Debian, which has a similar problem (the 32bit copy of libcap.so.2 is found at /lib32/libcap.so.2).

      These alternative library locations are mentioned in the Linux filesystem hierarchy standard (http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#LIBLTQUALGTALTERNATEFORMATESSENTIAL).

      The hard-coded /lib and /usr/lib paths in jsvc are counter-productive in the environments mentioned, and also in environments where the user expects to be able to control the library search path with the LD_LIBRARY_PATH environment variable. jsvc should be utilising the normal ld.so search path. This can be achieved even with a desire to be able to load either version 1 or 2 of libcap (as requested in https://issues.apache.org/jira/browse/DAEMON-234) because you don't need to give a full path to dlopen, according to its man page on Linux:

      "If filename contains a slash ("/"), then it is interpreted as a (relative or absolute) pathname. Otherwise, the dynamic linker searches for the library as follows ... (see ld.so(8) for further details)"

      So the issue can be resolved by simply making libcap_locs contain the desired filenames rather than pathnames. Patch will be attached shortly.

      1. patch.txt
        0.5 kB
        Emily Middleton

        Activity

        Hide
        Emily Middleton added a comment -

        Let dlopen use the default search path for libraries

        Show
        Emily Middleton added a comment - Let dlopen use the default search path for libraries
        Hide
        Kevin Shaum added a comment -

        I ran afoul of this too, and I'm dropping back to jsvc 1.0.9 for now as a result.

        I'd suggest one minor change to the patch: check for libcap.so first, before the version-specific names. If a sysadmin has set up libcap.so as a symlink to indicate which version is preferred, jsvc should respect that preference.

        Show
        Kevin Shaum added a comment - I ran afoul of this too, and I'm dropping back to jsvc 1.0.9 for now as a result. I'd suggest one minor change to the patch: check for libcap.so first, before the version-specific names. If a sysadmin has set up libcap.so as a symlink to indicate which version is preferred, jsvc should respect that preference.
        Hide
        Mladen Turk added a comment -

        Patch applied.
        Thanks!

        Show
        Mladen Turk added a comment - Patch applied. Thanks!

          People

          • Assignee:
            Unassigned
            Reporter:
            Emily Middleton
          • Votes:
            5 Vote for this issue
            Watchers:
            7 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development