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

[SachinJindal]

Hello @sujit_k_singh  - ldconfig doesnt load  liboneagentproc and gives blank output...

#ldconfig -p | grep one

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

also have tried setting up below to 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

it throws a warning for 64bit and i wanted to supress the warning weather it doesnt do deep monitoring for 32bit.

Reason why i wanted to supress :- 

1)Oracle Siebel CRM has 32bit CLI which is being used heavily and every time user run the utility it throws the error.

2)Using CLI if we need to increase the number of servers which does task execution while adding it is taking this warning as a parameter/argument for that utility and update in config results startup errors..

Ideally if DT doesnt support 32bit they shouldnt impact those processes keeping just 64bit lib path and setting globally is not a best practice..

for now looking for even wrapper or workaround which can skip 32 bit deep monitoring or supress the warning/error as this is impacting application...

[sujit_k_singh]

Hi @SachinJindal 

Thanks for the update. Since ldconfig -p | grep one returns blank, it confirms the library isn't registered in the system's shared library cache this is expected for libraries loaded via LD_PRELOAD.

To suppress the warning for 32-bit processes, one option is to create a wrapper script that unsets LD_PRELOAD before invoking the 32-bit utility:

#!/bin/bash
unset LD_PRELOAD
exec /path/to/original/siebel_cli "$@"

This ensures the 32-bit CLI runs clean without the 64-bit .so being preloaded and prevents the warning from being misinterpreted as a parameter.

However,  you're right that the operator shouldn't globally set a 64-bit-only path when 32-bit processes exist. This is a known limitation of the cloud-native full-stack injection.

Thanks,

Sujit

[SachinJindal]

Thanks Sujit ... even if i use unset for LD_Preload we will still have below ERROR..

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.

Also do you think using Classic Full Stack will have same limitation or problem?