Keine Coredumps vom VDR aber von allen anderen Programmen.

Copperhead · 6. Februar 2014

Was genau sind denn die Voraussetzungen, dass bei einem Segfault ein Coredump erzeugt wird?

Code

% cat /proc/sys/kernel/core_pattern 
|/usr/lib/systemd/systemd-coredump %p %u %g %s %t %e

Code

% ulimit -c
unlimited

Wenn ich

Code

% sleep 200 &
% killall -SIGSEGV sleep

ausführe wird ein Coredump erzeugt und ich kann diesen über systemd-coredumpctl abrufen.

Gestartet wird der VDR über runvdr-extreme. Zuerst dachte ich, dass diese den Coredump irgendwie verschluckt, aber auch wenn ich den VDR direkt von der Konsole oder über ein kleines Service-File über systemd starte funktionieren die Coredumps nicht.

Was macht der VDR anders? Liegt es am vdr User?
Ich weiß nicht mehr weiter.

mini73 · 6. Februar 2014

Benutzt du "-u", um ihn als anderen User laufen zu haben?
Dann muss der vdr mit dem Parameter "--userdump" gestartet werden, glaube ich.

Lars.

Copperhead · 6. Februar 2014

Öhhm. Nein der vdr User ist fest einkompiliert. Aber ich werden es später testen.

Copperhead · 6. Februar 2014

OK. Userdump eingeschaltet, SIGSEGV an den VDR und es gibt wieder keinen Coredump.

Was nun?

mini73 · 6. Februar 2014

Keine Ahnung, bei mir hat's bisher immer einfach funktioniert.
Ist es sicher, dass "ulimit -c unlimited" in der vdr-Umgebung aktiv ist? Vielleicht mal in der runvdr eintragen?
Gibt's sonst noch was spezielles bei systemd, was man konfigurieren müsste? Mein Wissen endet hier leider.

Lars

lostinspc · 6. Februar 2014

Copperhead:

Habs mal wie von dir beschrieben ausprobiert, bei mir klappts auch nicht (auch arch 64)

Copperhead · 9. Februar 2014

Also selbst wenn ich coredumpctl deaktiviere, bekomme ich vom VDR keine Coredumps.

Wo sollen die denn liegen?

mini73 · 10. Februar 2014

In Theorie sammelt systemd die doch ein, oder?

Bei yaVDR lassen wir alle coredumps in ein Verzeichnis schreiben (Auszug aus runvdr):

Code

echo "/var/log/vdr/core.%p" > /proc/sys/kernel/core_pattern

Muss für systemd-Systeme aber nicht zielführend sein.

Aber der core_pattern sollte dir verraten, wo normalerweise Coredumps angelegt werden.
Bei systemd scheint es ja irgendwie durch systemd-coredump durchgeleitet zu werden (siehe deinen ersten Post).

Lars.

seahawk1986 · 10. Februar 2014

Zitat von mini73

In Theorie sammelt systemd die doch ein, oder?

Ja, /proc/sys/kernel/core_pattern piped alles an systemd-coredump und das sollte das dann ins journal schreiben:

Code

|/usr/lib/systemd/systemd-coredump %p %u %g %s %t %e

Leider funktioniert das bei mir aktuell für den VDR auch nicht (IIRC ging das aber schon mal) - ich vermute es hängt daran dass er als root gestartet wird und dann auf den User vdr droppt, denn laut der Manpage von core gelten da einige Beschränkungen:

Zitat von core(5)

http://man7.org/linux/man-pages/man5/core.5.html[/url]]There are various circumstances in which a core dump file is not
produced:

* The process does not have permission to write the core file. (By
default the core file is called core, and is created in the
current working directory. See below for details on naming.)
Writing the core file will fail if the directory in which it is to
be created is nonwritable, or if a file with the same name exists
and is not writable or is not a regular file (e.g., it is a
directory or a symbolic link).

* A (writable, regular) file with the same name as would be used for
the core dump already exists, but there is more than one hard link
to that file.

* The filesystem where the core dump file would be created is full;
or has run out of inodes; or is mounted read-only; or the user has
reached their quota for the filesystem.

* The directory in which the core dump file is to be created does
not exist.

* The RLIMIT_CORE (core file size) or RLIMIT_FSIZE (file size)
resource limits for the process are set to zero; see getrlimit(2)
and the documentation of the shell's ulimit command (limit in
csh(1)).

* The binary being executed by the process does not have read
permission enabled.

* The process is executing a set-user-ID (set-group-ID) program that
is owned by a user (group) other than the real user (group) ID of
the process. (However, see the description of the prctl(2)
PR_SET_DUMPABLE operation, and the description of the
/proc/sys/fs/suid_dumpable file in proc(5).)

* (Since Linux 3.7) The kernel was configured without the
CONFIG_COREDUMP option.

Alles anzeigen

Eventuell hilft es wenn man den VDR nicht als root startet und dann auf den User vdr droppen lässt, sondern einfach die capabilites des Prozess über systemd richtig setzt und sich den Identitätswechsel erspart...

Copperhead · 10. Februar 2014

OK. /prc/sys/kernel/core_pattern regelt das also.

Auf meinem Desktop ist das identisch und wenn ich dort den chromium mit SIGSEGV abschieße bekomme ich auch einen Coredump gezeigt.
Schieße ich auf dem VDR über die Konsole ein sleep 100 ab bekomme ich ebenfalls ein Coredump.

Könntest du mal testen, ob du ein Coredump bekommst, wenn du den VDR mit SIGSEGV abschießt?

Edit: seahawk1986: OK. Das werde ich mal testen.

mini73 · 10. Februar 2014

Wenn ich per "sudo kill -SIGSEGV $(pidof vdr)" den vdr abschieße, bekomme ich einen Coredump.

Lars.

Copperhead · 10. Februar 2014

So. VDR ohne festeinkompilierten User kompiliert. Und im Service File den User verbogen. Capabilities erstmal ignoriert.
VDR startet als vdr User. SIGSEGV und kein Coredump

User aus dem Service-File ausgetragen.
VDR startet als root. SIGSEGV und kein Coredump

Gut, vielleicht kommt beim VDR kein Coredump wenn man SIGSEGV macht.
Defektes OSD-Demo Plugin (anderer Thread) zum crashen gebracht. Kein Coredump

Um systemd auszuschließen habe ich dann osc** mit SIGSEGV abgeschossen. Das wird ebenfalls im Service-File auf einen User degradiert.
Dort kommt ein Coredump.

seahawk1986 · 10. Februar 2014

Zitat von Copperhead

Könntest du mal testen, ob du ein Coredump bekommst, wenn du den VDR mit SIGSEGV abschießt?

Aktuell bekomme ich unter Arch Linux damit keinen Coredump. Die letzten Coredumps des VDR wurden bei mir um den Jahreswechsel herum gesammelt als ich eine zweite VDR-Instanz als normaler User von der Shell aus gestartet und ein Plugin beim Laden einen Segfault produziert hatte.

Copperhead · 10. Februar 2014

Wenn ich den VDR auf der Konsole starte sehe ich auch, dass dort "Core dumped" steht. Aber im aktuellen Verzeichnis ist nichts anders und in coredumpctl taucht auch nichts auf.

Copperhead · 11. Februar 2014

kls: Du liest doch hier sicherlich mit. Ist ja dein eigenes Subforum.

Kannst du dir da einen Reim drauf machen? Was macht der VDR da anders?
Irgendwelche Ideen, wie man das debuggen kann?

UFO · 11. Februar 2014

Hat VDR evtl. keine Schreibrechte auf das Directory, in dem er ausgeführt wird?

CU
Oliver

Copperhead · 11. Februar 2014

Eigentlich sollen die Coredumps ja an systemd weitergegeben werden.
Aber selbst wenn ich den VDR manuell von /tmp aus starte, wird in /tmp kein Coredump abgelegt.

UFO · 11. Februar 2014

Hier bei mir erzeugt VDR einen Coredump.

Copperhead · 17. Februar 2014

Ich bekomme jetzt zumindest einen Coredump. Nur nicht so, wie ich das möchte. Ich hätte den Dump gerne in coredumpctl.

Was habe ich gemacht. Ein bisschen im Internet recherchiert und dann das core_pattern manipuliert.

Code

# mkdir -p /tmp/cores
# chmod a+rwx /tmp/cores/
# echo "/tmp/cores/core.%e.%p.%h.%t" > /proc/sys/kernel/core_pattern
# killall -SIGSEGV vdr


# ls /tmp/cores/
core.vdr.1388.vdr4arch.1392643896

Warum bekomme ich hier jetzt einen Coredump, aber nicht in coredumpctl?

Edit: OK. Ich komme der Sache näher. Coredump VDR 530MB (WTF?). Coredump O*C*M 19MB. Da funkt mir wohl irgendwo ein Sizelimit rein.
Edit2: Und hier der entsprechende Bug dazu: https://bugs.freedesktop.org/show_bug.cgi?id=55613
Edit3: Hmm. Als Maximum ist aber 767MB definiert --> http://cgit.freedesktop.org/sy…al/coredump.c?id=v208#n44

mini73 · 17. Februar 2014

Wau, das ist ja ein großer Dump, ich weiß gar nicht, wie groß meine sind...
Gerade mal nachgesehen: zwischen 730 und 790MB. Noch mal "Wau"...

Lars.

Keine Coredumps vom VDR aber von allen anderen Programmen.

Jetzt mitmachen!

Teilen