Non-fatal error from /etc/

My domain is: (and others)

I ran this command: /snap/bin/certbot renew

It produced this output:
ERROR: object '/lib/x86_64-linux-gnu/' from /etc/ cannot be preloaded (cannot open shared object file): ignored.
This error seems to be a nuisance level message only. Certbot continues to run, and presumably renewals work, but any machine that has Dynatrace OneAgent installed causes this message to be emitted for any certbot operation (including asking for the certbot version).

My web server is (include version): nginx/1.18.0

The operating system my web server runs on is (include version): Ubuntu 20.04.4 LTS

My hosting provider, if applicable, is: Self hosted. EC2 on AWS.

I can login to a root shell on my machine: Yes

I'm using a control panel to manage my site: No

The version of my client is: 1.30.0 (Snap)

Hi @dale-c-anderson, and welcome to the LE community forum :slight_smile:

Are there other versions of certbot installed?
Were any add-ons or plug-ins installed?


@rg305 No other certbot versions installed, no other certbot plugins or add-ons. They're all stock certbot installations.

The dynatrace oneagent installer populated the /etc/ file with a single line, /lib/x86_64-linux-gnu/, and ever since then the error has been happening, but it only happens with certbot.

The other variant of the error from syslog that appears is
ERROR: object '/lib/x86_64-linux-gnu/' from /etc/ cannot be preloaded (failed to map segment from shared object): ignored.

I'm also following up with dynatrace support, but given that this message is only emitted when certbot is used, it seems possible that it's a certbot problem, and not a dynatrace oneagent problem.

1 Like


What say ye?


I presume you have checked the permissions? Are you running certbot with sudo or from root user?


I'm pretty sure you'd get this warning/non-fatal error for any program you're running. I don't see why it should be limited to Certbot.

From man

          File containing a whitespace-separated list of ELF shared
          objects to be loaded before the program.  See the
          discussion of LD_PRELOAD above.  If both LD_PRELOAD and
          /etc/ are employed, the libraries specified
          by LD_PRELOAD are preloaded first.  /etc/ has
          a system-wide effect, causing the specified libraries to
          be preloaded for all programs that are executed on the
          system.  (This is usually undesirable, and is typically
          employed only as an emergency remedy, for example, as a
          temporary workaround to a library misconfiguration issue.)

Note the "/etc/ has a system-wide effect, causing the specified libraries to be preloaded for all programs that are executed on the system." part.


It might be due to this Dynatrace library being incompatible with the versions of the shared libraries which ship inside the Certbot snap (and the core20 base).

I think it's harmless. We could do something like this to prevent /etc/ from affecting the Certbot snap, but it's not clear whether we'd break other users' environments by doing that, so I think we will probably do nothing in this case.


Would that generate a "cannot open shared object file" error message? Sounds a bit strange to me if it's an incompatibility issue.

Although that exact error message is present in that RPi fix in OpenJDK.. :thinking: Weird.


Certbot runs as root (in a nightly cron job that attempts to renew the installed certs).

1 Like

It is harmless, but it's also noisy @Osiris @_az. Certbot is the only process on any of these machines that cause that error to be emitted, which I find really odd.

In any case, without being able to prevent certbot from trying to load this library, the only other option I see is to mute all messages from certbot renewal attempts, which has the unpleasant side effect of blinding me to actual renewal problems.

1 Like

The only thing I can think of is if you:

  1. Put the preload into /etc/ rather than into /etc/ (This is required to make step 2 work).

  2. Run:

    systemctl edit snap.certbot.renew.service

    settting the contents of entire file to:


    followed by running:

    ldconfig && systemctl daemon-reload

then the renewal service shouldn't emit the warning message you're seeing from the dynamic linker.

Edit: hopefully the ld cache doesn't make this ineffective, I'm not sure since I wasn't able to completely accurately reproduce your scenario.


Ah interesting suggestion @_az . I'll give that a whirl, though I'm not sure how long it would last; the agent's updater might put the preload back in place before too long. I'll also bring it to the dynatrace team and see what they think. I can see why they want the library laced into everything, but by the same token, it seems like they're setting themselves up for a world of support woes by doing so.