Sundtek Support Forum

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.

Danke für die schnelle Antwort!
Das mit dem preloaden des mediaclient bekomme ich sicher hin. In dem script steht dann hinter dem libmediaclient.so das vdr.real (also das umbenannte binary)?
Wie VDR im Container gestartet wird weiß ich leider nicht. Dazu muss ich mich mal schlau machen, bin noch nicht so lange in der Docker-Welt unterwegs. Aber ich mach mich mal dran, auf jeden Fall hilft mir der Hinweis schonmal weiter.
Axel 

Hallo zusammen,
ich habe auf einem aktuellen Debian-System in Docker tvheadend laufen, das funktioniert mit einem SkyTV Ultimate 6 wunderbar nachdem ich im Wiki und hier im Forum alle nötigen Informationen finden konnte.
Jetzt möchte ich gerne VDR testen. (Natürlich läuft dann der tvheadend container nicht) Ich habe also auf dem host mit "./sundtek_netinst.sh -dockerhost" die nodes erzeugt. Im VDR-Container (ghcr.io/lapicidae/vdr-server) dann Treiberinstallation mit "./sundtek_netinst.sh -docker -use-custom-path /config" und der anschließende Aufruf von "/config/opt/bin/mediaclient -e" zeigt auch den angeschlossenen Stick. Ebenfalls sind /dev/dvb und /dev/bus/usb in den Container durchgereicht (alles genau wie im tvheadend-Container)
Trotzdem kommt beim start des vdr-Containers immer die folgende Fehlermeldung:
ERROR (dvbdevice.c,1945): /dev/dvb/adapter0/frontend0: No such device or address
Das Device ist aber vorhanden wenn ich im Container ein ls mache.
Jetzt bin ich mit meinem Latein am Ende und hoffe das mir vielleicht hier im Forum jemand helfen kann.
Axel

Moin, die Versuche mit Mediaclient waren nur als Test gedacht, um zu erfahren ob die Schaltung grundsätzlich funktioniert. Sonst nichts. Dass mit der Spannung, die zuerst aktiviert werden muss, macht natürlich Sinn... Ich teste das nachher, wenn ich Zuhause bin. Ich fange bei dem Thema quasi bei Null an und will im Prinzip nur zwei meiner Enigma2 ersetzen. Die nutze ich ausschließlich zum Streamen, was eigentlich Quatsch ist...

/var/packages/tvheadend/var/input/linuxdvb

ich denke das ist dort, den Inhalt einfach löschen.

1. TVHeadend stoppen
2. Inhalt löschen
3. TVHeadend starten, das baut die Konfiguration nochmal auf.