sd_notify(0, "READY=1\nSTATUS=Ready") früher aufrufen?

MarkusE · 9. Mai 2021

Hallo,

Mein vdr blieb in vdr.c:817 "cDvbDevice::Initialize();" hängen:

Code

(gdb) bt
#0  __semtimedop (semid=0, sops=0x7ffd68d54390, nsops=2, timeout=0x0) at ../sysdeps/unix/sysv/linux/semtimedop.c:33
#1  0x00007f86943a02fd in  () at /opt/lib/libmediaclient.so
#2  0x00007f86943a67ab in  () at /opt/lib/libmediaclient.so
#3  0x00007f869439e811 in  () at /opt/lib/libmediaclient.so
#4  0x00007f869439f5a4 in open () at /opt/lib/libmediaclient.so
#5  0x00007f869439f675 in open64 () at /opt/lib/libmediaclient.so
#6  0x00005583e3273334 in open64 (__oflag=0, __path=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/fcntl2.h:53
#7  cDvbDevice::Exists(int, int) (Adapter=<optimized out>, Frontend=<optimized out>) at dvbdevice.c:1947
#8  0x00005583e32745e5 in cDvbDevice::Initialize() () at dvbdevice.c:2024
#9  0x00005583e32454ee in main(int, char**) (argc=<optimized out>, argv=<optimized out>) at vdr.c:817

Alles anzeigen

vermutlich ein Fehler im DVB Treiber .

Systemd hat also nicht mitbekommen, dass vdr schon gestartet war. Und, nach dem timeout, vdr nochmal gestartet. Und nochmal. Und nochmal ...

Ich hatte sehr viele VDR Prozesse, und ein sehr träges System.

Klar, ist ein Fehler im Treiber, der sollte gefixd werden.

Trotzdem: Wäre es möglich, den Aufruf von "sd_notify(0, "READY=1\nSTATUS=Ready");" im VDR weiter noch oben zu schieben, direkt nach dem Laden der Konfigurationsdateien?

~Markus

seahawk1986 · 9. Mai 2021

Bei yaVDR ist das so gelöst dass der VDR erst gestartet wird, wenn der Sundtek-Treiber die angeschlossenen Tuner initialisiert hat - dazu muss man die udev-Regel und die sundtek.service anpassen, damit der mediasrv lang genug wartet (achtung, das sind Ansible-Templates, die kann man Systemd nicht 1:1 unterschieben):

https://github.com/yavdr/yavdr…mediasrv-sundtek.rules.j2

https://github.com/yavdr/yavdr…ystemd/sundtek.service.j2

MarkusE · 13. Mai 2021

Hallo,

bei mir gibt systemctl cat sundtek (nach der Installation des sundtek treibers) :

Zitat

# /lib/systemd/system/sundtek.service

[Unit]

Description=Sundtek MediaTV

Wants=graphical.target

[Service]

Type=oneshot

ExecStart=/opt/bin/mediaclient --start=4

ExecStop=/opt/bin/mediaclient --shutdown

RemainAfterExit=yes

[Install]

WantedBy=multi-user.target

Alles anzeigen

überzeugt mich irgendwie nicht. Da steht "Wants=graphical.target". Wozu braucht er das?

Bei yaVDR, wird diese Datei nach der Installation des sundtek Treibers durch eure Datei ersetzt?

kls · 13. Mai 2021

Nur 'ne kurze Anmerkung: ich selber benutze VDR nicht mit systemd, daher kann ich dazu nichts sagen.

Wenn da was geändert werden soll, müsste mir bitte jemand einen entsprechenden Patch schicken.

seahawk1986 · 13. Mai 2021

Zitat von MarkusE

Bei yaVDR, wird diese Datei nach der Installation des sundtek Treibers durch eure Datei ersetzt?

Die Dateien werden vom Playbook nach /etc geschrieben und sollten dann die Dateien des Treibers ersetzen. Das Playbook selbst installiert den sundtek-Treiber aus einem Paket, das darauf getrimmt ist, keine Dinge zu installieren, die stören würden.

wirbel · 13. Mai 2021

Wenn man sd_notify() früher starten würde, dann würde der VDR Prozess trotzdem für immer hängen.

MarkusE · 13. Mai 2021

Zitat von wirbel

Wenn man sd_notify() früher starten würde, dann würde der VDR Prozess trotzdem für immer hängen.

Stimmt. Aber immerhin würde systemd dann nicht laufend weitere vdr Prozesse starten, die dann auch für immer hängen ...

seahawk1986 · 13. Mai 2021

Kannst du mal deine Systemd-Unit für den VDR zeigen?

Systemd sollte da keine weiteren Prozesse spawnen - das wartet, bis der gespawnte Prozess meldet, dass er bereit ist (nutzt deine Unit Type=notify?) und wenn das nicht innerhalb des Timeouts passiert, sollte es ihn killen und je nach Restart-Anweisung erneut starten.

wirbel · 13. Mai 2021

Was dieses Problem sogar lösen könnte.

MarkusE · 13. Mai 2021

systemctl cat vdr:

Code

# /lib/systemd/system/vdr.service
[Unit]
Description=Video Disk Recorder
After=network.target

[Service]
Type=notify
ExecStartPre=/bin/bash /usr/lib/vdr/merge-commands.sh "commands"
ExecStartPre=/bin/bash /usr/lib/vdr/merge-commands.sh "reccmds"
ExecStart=/usr/bin/vdr
Restart=on-failure
RestartPreventExitStatus=0 2

[Install]
WantedBy=multi-user.target

# /etc/systemd/system/vdr.service.d/override.conf
[Unit]
#After=network.target media-sheeva\x2dplug-md0.mount lircd.service
After=network.target lircd.service media-rpi4s-md0.mount

[Service]
TimeoutStartSec=3000
Environment="HOME=/var/lib/vdr"
Environment="DISPLAY=:0.0"
Environment="VDPAU_NVIDIA_SYNC_DISPLAY_DEVICE=DFP-1"
Environment="__GL_SYNC_TO_VBLANK=1"
Environment="__GL_SYNC_DISPLAY_DEVICE=DFP-1"
#ExecStartPre=/bin/mount /media/sheeva-plug/md0
ExecStartPre=/usr/bin/irsend send_once EXTB_TX M1
ExecStartPost=/usr/bin/irsend send_once EXTB_TX M1
LimitCORE=infinit

Alles anzeigen

TimeoutStartSec=3000 war früher sehr viel kleiner, das habe ich wegen dem hier beschriebenen Problem hochgesetzt.

sd_notify(0, "READY=1\nSTATUS=Ready") früher aufrufen?

Jetzt mitmachen!

Teilen