If you setuid(2) or use capabilities(7) on a Netprobe it will ignore any LD_LIBRARY_PATH and only system directrories and the current working directory will be searched
When setting up a Netprobe to run X-* plugins you can either run it as root or with fine grained capabilities. Either of these methods will result in the LD_LIBARRY_PATH being ignored which in turn results in a failure to load required dynamic libraries. This means a Netprobe running X-* plugins and others may not work correctly. Even the included libssl.so and libpcap.so may not be found if the Netprobe is started outside it's installation directory.
Scope: All the information in this FAQ applies only to Linux. Other UNIX-type OSes, such as Solaris, have their own systems to deal with this scenario which may be subtly different. Nothing here applies to Windows.
In certain conditions the Linux dynamic linker will ignore LD_LIBRARY_PATH and some other environment variables. From ld.so(8):
This means that if the Netprobe binary has either SETUID or capabilties(7) set then only pre-configured directories are searched for shared library files.
This matters for a number of plugins which load external libraries including the X-* plugins themselves - which are the primary reason for using elevated privileges on a Netprobe. On most systems the only directories searched are those pre-defined in /etc/ld.so.cache - generated using ldconfig - and the current directory. In most cases the Netprobe is executed in the installation directory and so that directory is searched for shared library files but if the Netprobe is executed from somewhere else, for example using the Best Practise Templates scripts such as netprobectl then the Netprobe will be started with a working directory different from the install location and so none of the shipped shared libraries will be found.
There are a number of ways of working around this and the choice will be dependent on local installation practises and the combination of circumstances that most closely match: