vdr generiert coredump beim systemctl stop

crow · 17. Oktober 2016

beim einem sauberes stop über ssh wird eine coredump generiert. mir sagt der nicht viel, vielleicht findet sich jemand hier der mit weiterhelfen kann Ursache zu finden
ES geht um das VDR I aus meinem signature, es wird nur ein Eingang von L4M Twin DVB-S2 6.2 verwendet, und VDR wird mit -D0 gestartet.

Code

$ sudo systemctl status vdr
● vdr.service - Video Disk Recorder
   Loaded: loaded (/usr/lib/systemd/system/vdr.service; enabled; vendor preset: disabled)
   Active: failed (Result: signal) since Sun 2016-10-16 22:32:40 CEST; 19min ago
  Process: 599 ExecStart=/usr/bin/vdr (code=killed, signal=ABRT)
 Main PID: 599 (code=killed, signal=ABRT)
   Status: "Ready"


Oct 16 22:32:40 vdrhost vdr[599]: [599] [softhddev]GetSpuDecoder:
Oct 16 22:32:40 vdrhost vdr[599]: [599] saved setup to /var/lib/vdr/setup.conf
Oct 16 22:32:40 vdrhost vdr[599]: [693] device 1 section handler thread ended (pid=599, tid=693)
Oct 16 22:32:40 vdrhost vdr[599]: [692] frontend 0/0 tuner thread ended (pid=599, tid=692)
Oct 16 22:32:40 vdrhost vdr[599]: [1059] device 1 TS buffer thread ended (pid=599, tid=1059)
Oct 16 22:32:40 vdrhost vdr[599]: terminate called without an active exception
Oct 16 22:32:40 vdrhost systemd[1]: vdr.service: Main process exited, code=killed, status=6/ABRT
Oct 16 22:32:40 vdrhost systemd[1]: Stopped Video Disk Recorder.
Oct 16 22:32:40 vdrhost systemd[1]: vdr.service: Unit entered failed state.
Oct 16 22:32:40 vdrhost systemd[1]: vdr.service: Failed with result 'signal'.

Alles anzeigen

Code

url: https://cryptobin.co/98j5n241
pass: media

VDR plugins und start arguments, auch ohne boeseplugin wird der selber coredump generiert:

Code

# vdr --showargs
--chartab=ISO-8859-15
--device=0
--grab=/tmp
--log=3
--lirc=/run/lirc/lircd
--shutdown=/usr/lib/vdr/bin/shutdown-wrapper
--userdump
--watchdog=90
--plugin=dbus2vdr --nulldevice=force
--plugin=boeseplugin -d
--plugin=femon
--plugin=softhddevice

Alles anzeigen

M-Reimer · 17. Oktober 2016

Welche Distribution? Wie wird der nötige X-Server gestartet?

Riecht für mich nämlich verdächtig nach: https://github.com/VDR4Arch/vdr4arch/issues/121

Eigentlich gehört das bei softhddevice gemeldet, aber da es um dieses Plugin aktuell sehr ruhig ist...

Softhddevice verträgt es überhaupt nicht, wenn der X-Server beendet wird, wenn der VDR noch läuft.

Eventuell wird die Situation durch diese Anpassung entschärft: https://github.com/VDR4Arch/vd…21#issuecomment-204676376

Das Problem ist, dass der X-Server so gestartet wird, dass er in einer User-Session läuft. Diese Session wird dann aber von keinem Programm genutzt. Die oben genannte Änderung verhindert das Anlegen einer Session.

100% unkompliziert und stabil wird das ganze wenn man Kodi davorbaut, aber das ist nicht für jeden eine akzeptable Lösung.

crow · 17. Oktober 2016

Entschuldige, ich habe es nicht extra erwähnt da ich es in meine Signatur geschrieben habe. Ist eine Archlinux x86_64 bit Installation, mit vdr4arch, aber Paketen sind selbst gebaut ohne etwas zu verändern im PKGBUILD. Ich werde es versuchen so wie es geschrieben hast zu machen um einen segfault zu erstellen, falls mir das geling werde es hier posten.
Derzeit ist das Setup ohne Kodi, aber vor habe ich den auch zu verwenden, deshalb das dbus2vdr plugin mit --nulldevice=force argument, jedoch nicht für Live TV, da finde ich immer noch VDR dafür mehr geeignet.

crow · 17. Oktober 2016

- Eventuell wird die Situation durch diese Anpassung entschärft:

Code

https://github.com/VDR4Arch/vdr4arch/issues/121#issuecomment-204676376

So eine Zeile existiert nicht bei mir. Die ist laut vdr4arch commit am Feb 13 gepatch bzw. gelöscht, jedoch immer noch im orginal source von xlogin vorhanden:

Code

https://github.com/VDR4Arch/vdr4arch/commit/f62ac6f837245be47271759b2d00f739d9758a1c

Da gab es noch eine änderung im xlogin vielleicht kann das uns etwas helfen?

Code

https://github.com/joukewitteveen/xlogin/commit/b802547dd66dc306325a20b5c79b0bf9c155d817

Ist diese meldung über "bus" etwas zu beachten?

Spoiler anzeigen

crow · 17. Oktober 2016

Nach kill vom Xorg bzw. danach umschalten ein coredump wird erstellt

Spoiler anzeigen

Code

# ps aux | grep Xorg
root       484  0.3  0.3 283276 51064 tty7     Ssl+ 21:41   0:03 /usr/lib/xorg-server/Xorg -noreset vt7
# pkill X
# ps aux | grep Xorg
#




Oct 17 21:59:26 vdrhost vdr[596]: [719] ERROR: TS packet not accepted in Transfer Mode
Oct 17 21:59:26 vdrhost vdr[596]: [596] connect from 127.0.0.1, port 50498 - accepted
Oct 17 21:59:26 vdrhost vdr[596]: [596] switching to channel 8 (HOPE Channel HD)
Oct 17 21:59:26 vdrhost vdr[596]: [719] [softhddev]Clear:
Oct 17 21:59:26 vdrhost vdr[596]: [719] ERROR: TS packet not accepted in Transfer Mode
Oct 17 21:59:26 vdrhost vdr[596]: [719] [softhddev]Clear:
Oct 17 21:59:26 vdrhost vdr[596]: [719] ERROR: TS packet not accepted in Transfer Mode
Oct 17 21:59:26 vdrhost vdr[596]: [719] [softhddev]Clear:
Oct 17 21:59:26 vdrhost vdr[596]: [719] ERROR: TS packet not accepted in Transfer Mode
Oct 17 21:59:27 vdrhost vdr[596]: [719] [softhddev]Clear:
Oct 17 21:59:27 vdrhost vdr[596]: [719] ERROR: TS packet not accepted in Transfer Mode
Oct 17 21:59:27 vdrhost vdr[596]: audio/alsa: start delay 336ms
Oct 17 21:59:27 vdrhost vdr[596]: [719] [softhddev]Clear:
Oct 17 21:59:27 vdrhost vdr[596]: [719] ERROR: TS packet not accepted in Transfer Mode
Oct 17 21:59:27 vdrhost vdr[596]: audio/alsa: using device 'default'
Oct 17 21:59:27 vdrhost vdr[596]: [719] [softhddev]Clear:
Oct 17 21:59:27 vdrhost vdr[596]: audio/alsa: start delay 336ms
Oct 17 21:59:27 vdrhost vdr[596]: [719] ERROR: TS packet not accepted in Transfer Mode
Oct 17 21:59:27 vdrhost vdr[596]: audio/alsa: using device 'default'
Oct 17 21:59:27 vdrhost vdr[596]: [719] [softhddev]Clear:
Oct 17 21:59:27 vdrhost vdr[596]: audio/alsa: start delay 336ms
Oct 17 21:59:27 vdrhost vdr[596]: [719] ERROR: TS packet not accepted in Transfer Mode
Oct 17 21:59:27 vdrhost vdr[596]: [596] [softhddev]SetPlayMode: 0
Oct 17 21:59:27 vdrhost kernel: vdr[596]: segfault at 0 ip           (null) sp 00007ffd98acbb78 error 14 in vdr[400000+173000]
Oct 17 21:59:27 vdrhost systemd[1]: Created slice system-systemd\x2dcoredump.slice.
Oct 17 21:59:27 vdrhost systemd[1]: Started Process Core Dump (PID 808/UID 0).
Oct 17 21:59:28 vdrhost kernel: nvidia-modeset: Freed GPU:0 (GPU-e20d01a0-efa9-d57e-2ca9-6c376d7eb2d8) @ PCI:0000:01:00.0
Oct 17 21:59:28 vdrhost systemd[1]: vdr.service: Main process exited, code=dumped, status=11/SEGV
Oct 17 21:59:28 vdrhost systemd[1]: vdr.service: Unit entered failed state.
Oct 17 21:59:28 vdrhost systemd[1]: vdr.service: Failed with result 'core-dump'.
Oct 17 21:59:28 vdrhost systemd[1]: vdr.service: Service hold-off time over, scheduling restart.
Oct 17 21:59:28 vdrhost vdr[813]: [813] VDR version 2.2.0 started
#

Alles anzeigen

Code

url: https://cryptobin.co/e2c627x4
pass: media

seahawk1986 · 18. Oktober 2016

Was für mich (aktuell auf einem Testsystem mit Ubuntu 16.04) gut funktioniert ist eine Reihenfolge und Abhängigeit zwischen vdr.service und x@vt7.service zu definieren - das ist dann so ein Snippet für die vdr.service als /etc/systemd/system/vdr.service.d/override.conf:

Code

[Unit]
BindsTo=x@vt7.service
After=x@vt7.service

crow · 18. Oktober 2016

Habe das bei mir probiert, beim ersten systemctl stop vdr gab es keinen coredump, wieder vdr gestartet, noch einmal stop und da war es schon.

vdr.service: Main process exited, code=killed, status=6/ABRT

Code

url: https://cryptobin.co/s2o0u975
pass: media

wenn ich nur Xorg abschieße:
vdr.service: Main process exited, code=dumped, status=11/SEGV

Code

url: https://cryptobin.co/s3l8d286
pass: media

cat /etc/systemd/system/vdr.service.d/override.conf

Spoiler anzeigen

Edit #1
Ich verwende doch nicht das softhddevice PKGBUILD von vdr4arch da bei mir opengl variante nicht funktioniert hat

Code

http://www.vdr-portal.de/board16-video-disk-recorder/board55-vdr-plugins/p1279785-softhddevice-openglosd-mit-patches-von-jrie/#post1279785

es ist "nur" orginal vdr-developert git commit _gitver=4fa4f6616a17fe38344d28bd186a493d89ef3b85 ohne den openglosd patch! Da sehe ich aber dass johns noch zwei commits gemacht hat und der aktuelle ist der: 6dfa88aecf1b5a4c5932ba278209d9f22676547f

Code

prepare() {
  cd "${srcdir}/vdr-plugin-${_plugname}"


  # Disable OSS. Arch Linux doesn't ship OSS
  sed -i '/OSS /d' Makefile


  # Enable this to increase AV_INFO logging
  #sed -i 's/3000/500/g' Makefile


  # Enable this to compile with debug logging
  #sed -i 's/# -DDEBUG/-DDEBUG/g' Makefile


#  filterdiff -x '*.po' "$srcdir/48fbfa9f...569fde5d.diff" | patch -p1
}

Alles anzeigen

M-Reimer · 24. Dezember 2016

Weitergeleitet nach: https://projects.vdr-developer.org/issues/2452
Links zu den Coredumps sind leider tot, aber johns sollte das Problem eigentlich leicht nachstellen können.

M-Reimer · 22. Februar 2017

Nochmal kurz zu dem Thema: Bei vdr4arch haben wir auf ein neues "Verfahren" zum Starten des X-Server umgestellt.
Zum Testen bitte:

xlogin@vdr deaktivieren (systemctl disable xlogin@vdr)
Paket "vdr-xorg" installieren

Dann am besten sicherheitshalber einmal rebooten, dass xlogin wirklich weg ist und der neue Service sauber gestartet ist.

Bitte um Feedback.

Der neue Weg nutzt nurnoch die Helper-Services von xlogin und nicht mehr xlogin selbst. Damit wird der X-Server, sofern "vdr-xorg" installiert ist, noch fester mit dem VDR-Service verknüpft. Die Hoffnung ist, dass systemd damit definitiv die Reihenfolge kennt.

Im Umkehrschluss haben wir jetzt aber auch ein VDR-Servicefile welches keinerlei Abhängigkeiten zum X-Server mehr hat. Diese sind ins Paket "vdr-xorg" ausgelagert. Wer also headless fahren will hat hier optimale Voraussetzungen bei vdr4arch.

vdr generiert coredump beim systemctl stop

Jetzt mitmachen!

Teilen

Benutzer online in diesem Thema