3
« Letzter Beitrag von JohannesE am Februar 12, 2026, 12:30:45 Vormittag »
I did some more tests:
Without ld.so.preload the server runs stable without any problems.
With ld.so.preload, i get the problem after some time (< 24 hours).
I opened a tty console on the server and started "strace -ff" for this bash process.
Then, when the server got unstable, i called 'ls' in this console and examined the strace output.
I asked ChatGPT to analyse the strace logs; with this result:
The trace shows, that the bash (parent) blocks for a long time in semtimedop(). The child process also blocks before execve("/usr/bin/ls") in semtimedop() and then in a read() on a pipe. Only after ~50 seconds does execve occur, after which ls runs normally (open ".", getdents64, write). This indicates that the blockage is not in the filesystem, but in the fork/exec/IPC synchronization path.
Suspected cause: Since libmediaclient.so is injected system-wide into bash, it may be causing deadlocks in a constructor, via pthread_atfork(), or by interposing libc calls (fork/exec/semop/read/…).Please check for atfork handlers, locks in constructors, and any hooking around fork/exec.
Most probable reason:
Since the library is loaded via /etc/ld.so.preload in bash itself, it stands to reason that libmediaclient.so either (a) registers pthread_atfork() handlers, (b) hooks libc functions (e.g., fork/exec/posix_spawn/semop/read), or (c) initializes threads/locks in the constructor. In multi-thread situations, this can lead to deadlocks in the fork child (classic: mutex is locked in the parent during fork, child takes over locked state, then a constructor/hook routine blocks). This manifests itself here as a blockage in semtimedop()/pipe handshake of bash before execve()."
I can send you the log files, if this will help to improve anything.
Neueste Beiträge