cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
danmichael
Dynatrace Guide
Dynatrace Guide

There are two workarounds that can be used on Linux to fully prevent the loading of the process module.

This can be useful for applications you don't want or need to instrument. For instance if the process module is causing crashes in some application.

 

LD_AUDIT environment variable

You can prevent the process module from being loaded by setting the LD_AUDIT environment variable to point to the oneagentaudit.so library provided with the agent installation. This is a special "auditing" library that will be called by the Linux loader on process startup and which can then block the loading of the process module into that process. In a default full stack agent installation the correct value would be the following:

 

LD_AUDIT=/opt/dynatrace/oneagent/agent/bin/current/linux-x86-64/liboneagentaudit.so

 

Important notes:

  • The auditing interface using the LD_AUDIT environment variable is only available on glibc based Linux systems (which covers almost all distributions except Alpine Linux)
  • The current implementation will cause the following error to be printed in the terminal: ERROR: ld.so: object '/$LIB/liboneagentproc.so' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored. This is not a problem and is simply a sign that the audit library is working correctly.

Separate mount namespace

The second alternative is to run the problematic program in a separate mount namespace and mount an empty file on top of /etc/ld.so.preload within that namespace. This basically hides the existence of the process module from that program while having no impact on the rest of the system. This can be achieved using the unshare command (with root rights):

 

unshare -m -- sh -c 'mount --bind /dev/null /etc/ld.so.preload && <program to execute>

 

For a permanent effect, the customer might have to add this command to some kind of a startup script or a systemd service file. In case they don't want to start the program as root, one can extend the command to run the final program as some other user like this:

 

unshare -m -- sh -c 'mount --bind /dev/null /etc/ld.so.preload && su -c "<program to execute>" <user>'

 

The above command is, for example, necessary in case of a systemd service file where the user has been set to a non-root user. So a service file like this...:

 

ExecStart=/path/to/binary
User=someuser

 

... needs to be modified into something like this:

 

ExecStart=/usr/bin/unshare -m -- /bin/sh -c 'mount --bind /dev/null /etc/ld.so.preload && su -c "/path/to/binary" someuser'
User=root

 

 

Version history
Last update:
‎29 May 2023 08:07 AM
Updated by:
Comments
ChadTurner
DynaMight Legend
DynaMight Legend

Thanks for sharing this work around @danmichael