DX NetOps dadaemon process fails to start after server reboot

Products

• Network Observability
• CA Performance Management

Issue/Introduction

After system patching, when trying to restart the dadaemon process after the server has been restarted, it fails as per:


# service dadaemon status

Redirecting to /bin/systemctl status dadaemon.service
● dadaemon.service - Data Aggregator
Loaded: loaded (/etc/systemd/system/dadaemon.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Thu 2026-07-16 18:33:12 CDT; 2s ago
Process: 11625 ExecStart=/opt/CA/IMDataAggregator/scripts/dadaemon start sysd (code=exited, status=0/SUCCESS)
Main PID: 11704 (code=exited, status=1/FAILURE)

Jul 16 18:33:11 da_server systemd[1]: Starting Data Aggregator...
Jul 16 18:33:11 da_server dadaemon[11666]: Starting Apache ActiveMQ.
Jul 16 18:33:11 da_server dadaemon[11625]: Starting Data Aggregator.
Jul 16 18:33:11 da_server dadaemon[11625]: CEF:0|Broadcom|DX NetOps Data Aggregator|25.4.8.6|100|STARTING SERVICE|1|suser=root shost=da_server
Jul 16 18:33:11 da_server systemd[1]: Started Data Aggregator.
Jul 16 18:33:12 da_server systemd[1]: dadaemon.service: Main process exited, code=exited, status=1/FAILURE
Jul 16 18:33:12 da_server systemd[1]: dadaemon.service: Failed with result 'exit-code'.

Environment

DX NetOps CAPM all currently supported releases

Cause

Checking through the start log - netops-data-aggregator.out is where stdout/stderr from the java process actually lands, we see:

Exception in thread "main" java.lang.reflect.InvocationTargetException
Caused by: java.lang.UnsatisfiedLinkError: /tmp/bc-fips-jni_591998899287/libbc-probe.so: /tmp/bc-fips-jni_591998899287/libbc-probe.so: failed to map segment from shared object
         at org.bouncycastle.crypto.fips.NativeLoader.loadDriver(...)
         at org.bouncycastle.crypto.fips.FipsStatus.isReady(...)
         at org.bouncycastle.crypto.CryptoServicesRegistrar.<clinit>(...)
         at org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider.<init>(...)
         at com.ca.im.core.security.Encryption.init(Encryption.java:226)
         at com.ca.im.core.services.security.SSLConfigHandler.configureSSL(SSLConfigHandler.java:15)
         at com.ca.im.dm.aggregator.DataAggregator.checkSSL(DataAggregator.java:39)
         at com.ca.im.dm.aggregator.DataAggregator.main(DataAggregator.java:25)

The dadaemon process is trying to decrypt the keystore/truststore passwords in application.properties. To do that, it tries to initialize, which extracts a native JNI "probe" shared library into java.io.tmpdir (default /tmp) and tries to load it.

However, it gets a "failed to map segment from shared object" when loading out of /tmp

This is the textbook signature of /tmp being mounted with noexec privileges (very common on hardened/STIG/CIS-locked-down hosts). It can also come from /tmp being full or an SELinux denial, but noexec is by far the most common cause of this exact message.

Checking using mount | grep -w /tmp we see that the directory is set with noexec

/dev/mapper/rnel-tmp on tmp type xfs (rw, nosuid, nodev, relatime, atti2, inode64, 1ogbufs=8, 1ogbsize=32k, noquota, noexec)

 

Resolution

You can remove noexec on /tmp by running (as root user):

mount -o remount,exec /tmp

After this, dadaemon should start as normal.