Geneos - Netprobe fails to run X-* plugin due to shared library issues

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):

Secure-execution mode       
For security reasons, the effects of some environment variables are       
voided or modified if the dynamic linker determines that the binary       
should be run in secure-execution mode.  This determination is made       
by checking whether the AT_SECURE entry in the auxiliary vector (see       
getauxval(3)) has a nonzero value.  This entry may have a nonzero       
value for various reasons, including:       
*  The process's real and effective user IDs differ, or the real and          
effective group IDs differ.  This typically occurs as a result of          
executing a set-user-ID or set-group-ID program.       
*  A process with a non-root user ID executed a binary that conferred          
permitted or effective capabilities.       
*  A nonzero value may have been set by a Linux Security Module.

This means that if the Netprobe binary has either SETUID or capabilities(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:

1. Separate Netprobes for X-* plugins and others

   
   It may seem desirable to have a single Netprobe package that can be installed and used for all configurations but issues like the one detailed in this FAQ mean that it may be better to have a "normal" Netprobe installation and a separate one for X-* plugins where elevated privileges are required. However even in this case the Netprobe with capabilities may still have issues loading shared libraries that are not in the default search list of directories. In this case, assuming the list of shared libraries is small and the working directory of the Netprobe is different from the installation location, you can symlink all the shared libraries into the working directory using a command like:

   ln -s PATHTOINSTALL/*.so .

2. Add all directories normally in LD_LIBRARY_PATH to the system-side ld.so.cache using ldconfig and appropriate config files
   
   Depending on the age and the distribution of the Linux system you can add all the directories required to the system-wide ld.so.cache. This is usually done by adding files to the /etc/ld.so.conf.d directory, e.g. netprobe-libs, which list one directory per line of places to search. This can then be read into the cache using ldconfig(8) as root of, on most systems, this will be read after reboot. The downside is that if there are multiple versions of the Netprobe installed then only the first directory and shared library with a specific name matched will be used.