Symptom
Engine execution on Linux fails with:
EX001955S (1) Exstream needs version 1 of the Dynamic Link Library named (libExEngPageRunner.sl) instead of version .
The operating system message underneath is libExEngPageRunner.sl: cannot open shared object file: No such file or directory.
The confusing part is that the same run often works from an interactive shell, or Designer works fine, while execution through Command Center fails.
Cause
The runtime loader does not search the Exstream engine directory for shared libraries on its own. An interactive shell usually has a suitable environment because someone set it up once, but the Command Center service process starts with a different, smaller environment and never sees that path.
File presence alone is not enough. The service account must be able to read the engine directory, and the loader must be told where to look.
Fix
Add the engine directory to LD_LIBRARY_PATH for the process that actually launches the engine:
export LD_LIBRARY_PATH=/opt/exstream/engine:$LD_LIBRARY_PATH
Use your real engine installation path, and apply the setting in the supported Command Center or service launcher configuration so it survives service restarts. Setting it in a user's shell profile fixes the interactive case and nothing else.
Then check two more things: the service account has read permission on the engine directory, and the library architecture matches the engine binary. Restart the service and run a small job.
If a different shared-library error appears after the fix, that is progress, not failure.
Follow the chain: inspect the first missing dependency each time rather than copying libExEngPageRunner.sl around.
Compare the service environment with the shell
When a command works in a shell but fails under a scheduler or service, compare the two process environments before changing the installation.