Werk #19573: Fix system executables failing due to Checkmk's OpenSSL being loaded via LD_LIBRARY_PATH
| Component | Site management | ||
| Title | Fix system executables failing due to Checkmk's OpenSSL being loaded via LD_LIBRARY_PATH | ||
| Date | Apr 10, 2026 | ||
| Level | Prominent Change | ||
| Class | Bug Fix | ||
| Compatibility | Compatible - no manual interaction needed | ||
| Checkmk versions & editions |
|
Previously, Checkmk's site environment included $OMD_ROOT/lib in LD_LIBRARY_PATH
so that Checkmk's own processes could find the bundled shared libraries. The unintended
side effect: system executables invoked from within the site environment (e.g. ssh,
curl, openssl, zypper, systemctl, php) would also pick up Checkmk's bundled
OpenSSL instead of the system's version. On distributions where the two versions were
incompatible, those commands would fail with errors such as:
/usr/bin/systemctl: /omd/sites/mysite/lib/libcrypto.so.3: version OPENSSL_3.4.0 not found
As a workaround, Checkmk shipped wrapper scripts that unset LD_LIBRARY_PATH before
invoking the real system executable for a list of commonly affected commands.
We have now fixed the root cause: all Checkmk-shipped ELF binaries have their RUNPATH
correctly set so they locate their bundled libraries directly, without relying on
LD_LIBRARY_PATH. As a result, $OMD_ROOT/lib is no longer added to LD_LIBRARY_PATH,
and the workaround wrapper scripts have been removed.
LD_LIBRARY_PATH still includes $OMD_ROOT/local/lib to support native libraries
installed by site users (e.g. via MKPs). If you have placed a native shared library in
local/lib that is incompatible with a system executable, that executable may still fail
— but this is a rare edge case and can be resolved by removing the conflicting library.