Dynatrace cloud native installation Full-Stack observability

[SachinJindal]

Hello Team - have installed cloudnative full stack agent on Oracle Siebel CRM which consist of combination of 32bit and 64bit processes ... looks like agent is hardcoded to use 64bit so file and rest of 32 bits processes are throwing error on each and every pods..

Error :- 

************

ERROR: ld.so: object '/opt/dynatrace/oneagent-paas/agent/lib64/liboneagentproc.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.

ERROR: ld.so: object '/opt/dynatrace/oneagent-paas/agent/lib64/liboneagentproc.so' from /etc/ld.so.preload cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.

[xxxxPOD-0:/opt]#find . -name liboneagentproc.so

./dynatrace/oneagent-paas/agent/lib/liboneagentproc.so

./dynatrace/oneagent-paas/agent/lib64/liboneagentproc.so

Settings :- looks like hardcoded to use 64bit...

[POD]#env | grep PRELOAD

LD_PRELOAD=/opt/dynatrace/oneagent-paas/agent/lib64/liboneagentproc.so

[POD]#cat /etc/ld.so.preload

/opt/dynatrace/oneagent-paas/agent/lib64/liboneagentproc.so

we have both library file (32 and 64 bit) present on agent folder .. how can we instruct to use specific .so file based on bitness of the processes...??

[SachinJindal]

Any suggestions?

[sujit_k_singh]

Hi @SachinJindal 

The Cloud Native Full Stack operator hardcodes LD_PRELOAD to the lib64 path, which causes the error for 32-bit processes. The 32-bit library does exist on the agent (./agent/lib/liboneagentproc.so), it's just not being referenced.

Fix — Use the $LIB dynamic token:

Update /etc/ld.so.preload and LD_PRELOAD to: /opt/dynatrace/oneagent-paas/agent/$LIB/liboneagentproc.so

The Linux linker automatically resolves $LIB to lib for 32-bit and lib64 for 64-bit processes.

However, since the operator injects this automatically, I'd recommend raising a Dynatrace Support ticket they can confirm if there's a feature flag or operator version that handles mixed-bitness containers natively.

Thanks,

Sujit

[SachinJindal]

Thanks Sujit .. have tried this workaround looks $LIB is not working as dynamic token , automatically not resolving based on bitness of the process..

[sujit_k_singh]

Hi @SachinJindal 

The $LIB token behavior depends on the glibc version and the container's base image, verify your container base OS supports this token: ldconfig -p | grep liboneagentproc

If the container is musl-based rather than glibc-based, $LIB won't work at all.

However, instead of relying on $LIB, try specifying both libraries explicitly in /etc/ld.so.preload:

/opt/dynatrace/oneagent-paas/agent/lib64/liboneagentproc.so
/opt/dynatrace/oneagent-paas/agent/lib/liboneagentproc.so

The dynamic linker will ignore the library that doesn't match the process bitness (you'll still see a warning for the mismatched one, but the correct library will load). let me know the result.

Thanks,

Sujit