Running the Informatica Secure Agent on Ubuntu: Three Things That Break

The installer finishes cleanly. The agent registers, starts, and runs its first test mapping without a single warning. Then the first real production job crashes with a segfault.

If you run the Informatica Secure Agent on Ubuntu, you should expect this moment sooner or later. Ubuntu is not an officially certified operating system for the Secure Agent. It works surprisingly well most of the time, but when it does fail, the error message rarely describes the real problem.

In this blog, we walk through three failures we encountered while running the Secure Agent on Ubuntu 24.04:

• A “missing” library that was never actually missing
• A segfault that turned out to be an OpenSSL version clash
• A class-file version error caused by a mismatched Java runtime

For each one, we explain what the error looked like, what was really happening underneath, and the fix that finally held up.

Why a Clean Install Proves Very Little

The Secure Agent installs, registers, and starts without complaint. A first mapping against a well-behaved connector, such as PostgreSQL, runs successfully. At this point, it is tempting to consider the environment validated. It is not.

The agent ships with its own isolated ODBC configuration, which the startup scripts point to through the ODBCSYSINI environment variable. As a result, driver registration must happen in the agent’s own odbcinst.ini file, not in /etc/odbcinst.ini. This detail is easy to miss, because a system-wide driver install looks like it should be enough. It isn’t.

The agent also bundles its own driver manager and its own OpenSSL libraries. Both live under the agent’s drivers/ directory, and both silently take precedence over anything installed on the system. None of this becomes visible until you connect to something the DataDirect-oriented tooling was not designed for, such as a standard community MySQL ODBC driver.

The Missing-Library Symlink

The first real error on a fresh MySQL connection was:

[unixODBC][Driver Manager]Can't open lib 'MySQL ODBC 8.0 Unicode Driver' : file not found

Read literally, this says the driver file is missing. It wasn’t. Running ldd against the driver showed no unresolved dependencies.

The actual cause is stricter than a missing file. The driver manager resolves connections by the exact section name in odbcinst.ini, not by locating a file. If the registered stanza is not spelled [MySQL ODBC 8.0 Unicode Driver] character for character, the driver manager reports it as absent.

There is also a second, more difficult version of the same symptom. The agent’s bundled libodbc.so is not the plain unixODBC driver manager that the logs suggest. It is a repackaged DataDirect driver manager. We confirmed this through an md5sum mismatch against the real system library and a different internal version string found with strings.

DataDirect’s driver manager is built for Informatica’s own Oracle and SQL Server connectors, not for arbitrary third-party ODBC drivers. Because the ABI it expects does not match, it will report a correctly registered, dependency-clean MySQL driver as “not found.”

The fix is not a reinstall. Instead, point the agent at the system’s actual driver manager:

cd ~/informatica/agent/drivers/misc/base/bin
cp libodbc.so libodbc.so.datadirect_backup   # keep the originals
rm libodbc.so libodbc.so.2
ln -s /lib/x86_64-linux-gnu/libodbc.so.2 libodbc.so
ln -s /lib/x86_64-linux-gnu/libodbc.so.2 libodbc.so.2

Then restart the agent.

The Segfault That Is Really a Version Clash

Fix the driver manager and a new failure shows up, and it’s the scarier-looking one:

FATAL ERROR : Signal Received: SIGSEGV (11)

The log cuts off right after “Connecting to database.” This is exactly the failure that showed up in production. Here’s the actual job history from the environment, captured before the root cause was understood:

A generic segfault like this invites guessing about the driver version, the OpenSSL build, or the auth plugin. Every one of those guesses is a dead end here, because the actual cause lives one layer below the driver: a symbol collision inside the process itself.

This is where reaching for a debugger before touching any more configuration pays off. A targeted strace attached at the DTM process’s birth (standard ptrace attach was blocked by permissions, so this needed a launcher wrapper) produced a clean backtrace:

mysql_server_init -> OPENSSL_init_ssl -> CRYPTO_THREAD_run_once
  -> OBJ_NAME_add -> lh_insert  [resolved into libpmcrypto.so.1.0.0]
  -> SIGSEGV (NULL pointer dereference)

That single trace explains everything the config-level fixes couldn’t. Informatica’s DTM engine bundles its own ancient OpenSSL (libpmcrypto.so.1.0.0, roughly OpenSSL 1.0.0-era) for internal licensing use, and it loads first at DTM startup. Linux dynamic linking resolves symbols globally by default, so the first library loaded wins.

When the MySQL driver’s much newer bundled OpenSSL (1.1.1) later calls OPENSSL_init_ssl(), those calls get silently resolved to the old library’s symbols instead. The old library’s internal struct layout doesn’t match what the new caller expects, and the process dereferences a null pointer as soon as SSL init runs.

This is also why a blanket fix trades one crash for another. Forcing everything onto one OpenSSL version with a global LD_PRELOAD stops the MySQL crash, but it breaks DTM’s own HTTPS heartbeat to the cloud, because that traffic is now forced onto the wrong OpenSSL too.

A small shim that intercepts dlopen() calls and adds RTLD_DEEPBIND only when the MySQL driver is loading solves the problem without touching anything else DTM depends on.

The same “segfault is really a version clash” lesson shows up in the driver manager story from Section 2, just one layer up. Two concurrent ODBC connections in the same DTM process crashed or returned garbled diagnostics only when routed through the DataDirect-repackaged manager, yet connected fine through the system one. It was an ABI mismatch wearing a segfault’s clothes, and we found it the same way: by isolating the exact code path with controlled test scripts before changing anything in production.

Class-File Versions and Where Drop-In JARs Actually Load From

The same principle applies to a third, unrelated class of failure on the JVM side: don’t trust how the error frames the problem, and find the actual mismatch instead.

The Secure Agent ships with its own bundled JRE. Any custom transformation JAR or additional driver JAR placed in the agent’s plugin directories is usually compiled elsewhere, often against whichever JDK a developer happens to have installed. If that JAR was built with a newer JDK than the agent’s bundled runtime, the result is not a segfault. It is a java.lang.UnsupportedClassVersionError.

This is not a hypothetical problem. The same mechanism appears across the Java ecosystem whenever an agent carries its own JRE:

“…has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0”

This is the wording one automation agent vendor uses in its own support documentation. Their fix, unsurprisingly, was to update the JRE bundled with the agent rather than change the JAR.

An older case from a build agent plugin shows the same root cause in a different form. The JAR failed with UnsupportedClassVersionError: Bad version number in .class file when launched one way, yet worked fine when launched another way on the same machine. The two launch paths resolved JAVA_HOME differently and picked up two different JREs.

Both cases reinforce the lesson from Sections 2 and 3. The error names a symptom, such as a version number or a “not found” message, without naming the real conflict: which binary, from which path, is actually loaded at runtime. Before changing any dependency version, confirm exactly that:

unzip -p your-jar.jar META-INF/MANIFEST.MF | grep -i "build-jdk\|created-by"
~/informatica/agent/jre/bin/java -version

The first command shows which JDK built the JAR. The second shows which JRE the agent is actually running. Once you see both numbers side by side, the mismatch is usually obvious.

The Common Thread

All three failures disguise themselves as something else. A missing file turns out to be a naming mismatch. A segfault turns out to be a symbol collision. A version error turns out to be a runtime path problem.

In every case, the fix that held up came from tracing the process’s real behavior with tools such as strace, controlled isolation tests, and manifest inspection. Iterating on plausible-sounding configuration changes did not work.

On a supported operating system, most of these issues stay invisible because the vendor has already made these decisions for you. On Ubuntu, you make those decisions yourself, which also means you get to see exactly where they were made.

To understand your options before committing, read our guide on PowerCenter end of support and whether to move to IDMC or open source.

How Ksolves Can Help

Running Informatica on non-standard infrastructure demands deep knowledge of how the Secure Agent, DTM engine, and bundled libraries interact at runtime. Ksolves 24/7 Informatica support services help teams diagnose issues like these at the root, from ODBC driver conflicts to JVM runtime mismatches, without trial-and-error changes in production.

If you are planning a broader platform change, our Informatica consulting services cover architecture, environment setup, and connector provisioning. For teams still on PowerCenter, we also provide end-to-end PowerCenter to IDMC migration.