14 Mar
2019
14 Mar
'19
2:16 p.m.
Hallo,
ich möchte das ein chrashendes Programm einen core dump erzeugt. Gelesen habe ich:
Variante 1)
in etc/profile die Zeile "ulimit -c unlimited" ergänzen
Das funktioniert ganz prinzipiell.
Da das Programm aber schon von einem init-script gestartet wird hilft das nicht - kein
login.
Variante 2)
Auch ein Eintrag in das das Programm startende init-script wirkt nicht.
Variante 3)
Dann habe ich noch die Datei /etc/limits gefunden.
Den auskommentierten Eintrag:
#* L2 D6144 R2048 S2048 U32 N32 F16384 T5 C0 I20 O0
geändert zu
* L2 D6144 R2048 S2048 U32 N32 F16384 T5 C16384 I20 O0
oder auch nur
* C50000
bewirkt ebenfalls nichts.
Die 4. Alternative (in Programm eincompilieren) möchte ich eigentlich nicht.
Weiß jemand wie's trotzdem geht? Und warum die Varianten 2 und 3 nicht gehen?
Gruß
Arno
14 Mar
14 Mar
4:46 p.m.
Hallo Arno,
bei Variante 2 könnte das Problem sein, dass das Skript nit mit der passenden
Shell ausgeführt wird. Du kannst dort zu Diagnosezwecken ja mal (nach dem
ulimit -c unlimited) ein "ulimit -a >/tmp/ulimit.log 2>&1" einbauen.
Arno Steffens wrote (at 2019-03-14 14:16 +0100):
Hallo,
ich möchte das ein chrashendes Programm einen core dump erzeugt. Gelesen habe ich:
Variante 1)
in etc/profile die Zeile "ulimit -c unlimited" ergänzen
Das funktioniert ganz prinzipiell.
Da das Programm aber schon von einem init-script gestartet wird hilft das nicht - kein
login.
Variante 2)
Auch ein Eintrag in das das Programm startende init-script wirkt nicht.
Variante 3)
Dann habe ich noch die Datei /etc/limits gefunden.
Den auskommentierten Eintrag:
#* L2 D6144 R2048 S2048 U32 N32 F16384 T5 C0 I20 O0
geändert zu
* L2 D6144 R2048 S2048 U32 N32 F16384 T5 C16384 I20 O0
oder auch nur
* C50000
bewirkt ebenfalls nichts.
Die 4. Alternative (in Programm eincompilieren) möchte ich eigentlich nicht.
Weiß jemand wie's trotzdem geht? Und warum die Varianten 2 und 3 nicht gehen?
Gruß
Arno
--
Mit freundlichem Gruß / With kind regards
Holger Klawitter
--
listen <at> klawitter <dot> de
5:35 p.m.
Am Donnerstag, 14. März 2019 14:16 CET, "Arno Steffens" <epsi(a)gmx.de>
schrieb:
Hallo,
ich möchte das ein chrashendes Programm einen core dump erzeugt.
Tut es das wirklich nicht? Manchmal enden die an eigenartigen Plätzen. Was sagt denn:
$ sudo sysctl -a | grep kernel.core_pattern
oder auch:
$ cat /proc/sys/kernel/core_pattern
Gelesen habe ich:
Variante 1)
in etc/profile die Zeile "ulimit -c unlimited" ergänzen
Das funktioniert ganz prinzipiell.
Da das Programm aber schon von einem init-script gestartet wird hilft das nicht - kein
login.
Variante 2)
Auch ein Eintrag in das das Programm startende init-script wirkt nicht.
Variante 3)
Dann habe ich noch die Datei /etc/limits gefunden.
Den auskommentierten Eintrag:
#* L2 D6144 R2048 S2048 U32 N32 F16384 T5 C0 I20 O0
geändert zu
* L2 D6144 R2048 S2048 U32 N32 F16384 T5 C16384 I20 O0
oder auch nur
* C50000
bewirkt ebenfalls nichts.
Zum Glück :-)
Die Datei '/etc/limits' wird vom PAM-Subsystem benutzt. Das schlägt aber
gemeiniglich nur
beim Login und anderen Authenifizierungen zu.
Die 4. Alternative (in Programm eincompilieren) möchte
ich eigentlich nicht.
Weiß jemand wie's trotzdem geht? Und warum die Varianten 2 und 3 nicht gehen?
Bist Du sicher dass Du/Deine Herzensdistro nicht systemd benutzt? Der hat u.U. dann
den systemd-coredump installiert (das solltest Du aber in der Ausgabe der oben genannten
Shell Comands sehen - da steht dann so was wie '|/usr/lib/systemd/systemd-coredump %p
%u %g %s %t %e
'). Falls systemd da seine schmutzigen Hände drinn hat landen die Dumps (Drumroll
please) im Journal.
Von dort kann man sie mit 'coredumpctl' auflisten/anzeigen und dergl. mehr (what
where they smoking ..?).
Gruss RalfD
Gruß
Arno
7:17 p.m.
Am 14.03.2019 um 17:35 schrieb Ralf Mattes:
Ziemlich sicher, da es ein kleines Yocto-Linux ist.
Vielen Dank trotzdem für den Input.
Am Donnerstag, 14. März 2019 14:16 CET, "Arno Steffens" <epsi(a)gmx.de>
schrieb:
Mit diesem Befehl weise ich im gleichen Script, gleich neben dem ulimit
vorher den Platz und das Pattern zu, danach wird dann (ebenfalls im
gleichen Script) das chrashende binary aufgerufen.
Und das Pattern steht dann auch kontrollierbar drin, nur ulimit -c zeigt
0. :(
Hallo,
ich möchte das ein chrashendes Programm einen core dump erzeugt.
Tut es das wirklich nicht? Manchmal enden die an eigenartigen Plätzen. Was sagt denn
$ sudo sysctl -a | grep kernel.core_pattern
oder auch:
$ cat /proc/sys/kernel/core_pattern
PAM hab ich nicht (bewußt). Ich hatte das ulimit wie gesagt vorher im
/etc/profile - aber da wirkt es nur, wenn ich das binary manuell nach
einloggen aufrufe.
Gelesen habe ich:
Variante 1)
in etc/profile die Zeile "ulimit -c unlimited" ergänzen
Das funktioniert ganz prinzipiell.
Da das Programm aber schon von einem init-script gestartet wird hilft das nicht - kein
login.
Variante 2)
Auch ein Eintrag in das das Programm startende init-script wirkt nicht.
Variante 3)
Dann habe ich noch die Datei /etc/limits gefunden.
Den auskommentierten Eintrag:
#* L2 D6144 R2048 S2048 U32 N32 F16384 T5 C0 I20 O0
geändert zu
* L2 D6144 R2048 S2048 U32 N32 F16384 T5 C16384 I20 O0
oder auch nur
* C50000
bewirkt ebenfalls nichts.
Zum Glück :-)
Die Datei '/etc/limits' wird vom PAM-Subsystem benutzt. Das schlägt aber
gemeiniglich nur
beim Login und anderen Authenifizierungen zu. Die 4.
Alternative (in Programm eincompilieren) möchte ich eigentlich nicht.
Weiß jemand wie's trotzdem geht? Und warum die Varianten 2 und 3 nicht gehen?
Bist Du sicher dass Du/Deine Herzensdistro nicht systemd benutzt? Der hat u.U. dann
den systemd-coredump installiert (das solltest Du aber in der Ausgabe der oben genannten
Shell Comands sehen - da steht dann so was wie '|/usr/lib/systemd/systemd-coredump %p
%u %g %s %t %e
'). Falls systemd da seine schmutzigen Hände drinn hat landen die Dumps (Drumroll
please) im Journal.
Von dort kann man sie mit 'coredumpctl' auflisten/anzeigen und dergl. mehr (what
where they smoking ..?).
Gruss RalfD
Gruß
Arno
7:19 p.m.
Am 14.03.2019 um 16:46 schrieb Holger Klawitter:
Hallo Arno,
bei Variante 2 könnte das Problem sein, dass das Skript nit mit der passenden
Shell ausgeführt wird. Du kannst dort zu Diagnosezwecken ja mal (nach dem
ulimit -c unlimited) ein "ulimit -a >/tmp/ulimit.log 2>&1" einbauen.
Das probier ich mal, Danke Holger.
Arno Steffens wrote (at 2019-03-14 14:16 +0100):
Hallo,
ich möchte das ein chrashendes Programm einen core dump erzeugt. Gelesen habe ich:
Variante 1)
in etc/profile die Zeile "ulimit -c unlimited" ergänzen
Das funktioniert ganz prinzipiell.
Da das Programm aber schon von einem init-script gestartet wird hilft das nicht - kein
login.
Variante 2)
Auch ein Eintrag in das das Programm startende init-script wirkt nicht.
Variante 3)
Dann habe ich noch die Datei /etc/limits gefunden.
Den auskommentierten Eintrag:
#* L2 D6144 R2048 S2048 U32 N32 F16384 T5 C0 I20 O0
geändert zu
* L2 D6144 R2048 S2048 U32 N32 F16384 T5 C16384 I20 O0
oder auch nur
* C50000
bewirkt ebenfalls nichts.
Die 4. Alternative (in Programm eincompilieren) möchte ich eigentlich nicht.
Weiß jemand wie's trotzdem geht? Und warum die Varianten 2 und 3 nicht gehen?
Gruß
Arno
8:15 p.m.
Am Donnerstag, 14. März 2019 19:17 CET, Arno <epsi(a)gmx.de> schrieb:
? Wirklich? Yocto-Linux "kann" beides, sysVinit oder systemd.
Falls Dein Linux wirklich systemd nutzt (Test: $ ps -q 1 -o comm= ) dann würde ich schwer
anraten
für Deinen Daemon ein Service-File anzulegen und nicht den Initscript-Kompatibilitätsmodus
zu nutzen.
Dann kannst Du auch dort direkt die Limits verändern (in Deinem Fall: LimitCORE=....).
Gruss RalfD
Mit diesem Befehl weise ich im gleichen Script, gleich neben dem ulimit
vorher den Platz und das Pattern zu, danach wird dann (ebenfalls im
gleichen Script) das chrashende binary aufgerufen.
Und das Pattern steht dann auch kontrollierbar drin, nur ulimit -c zeigt
0. :(
Dann zeig' uns doch mal Dein Script. Du testest den Rückgabewert von 'ulimit'
?
[...]
PAM hab ich nicht (bewußt). Ich hatte das ulimit wie
gesagt vorher im
/etc/profile - aber da wirkt es nur, wenn ich das binary manuell nach
einloggen aufrufe.
Wenn Du /etc/limits hast dann hast Du wahrscheinlich auch PAM, das ist nämlich die
Config für das pam_limits Modul.
[...]
Bist Du sicher
dass Du/Deine Herzensdistro nicht systemd benutzt? Der hat u.U. dann
den systemd-coredump installiert (das solltest Du aber in der Ausgabe der oben genannten
Shell Comands sehen - da steht dann so was wie '|/usr/lib/systemd/systemd-coredump %p
%u %g %s %t %e
'). Falls systemd da seine schmutzigen Hände drinn hat landen die Dumps (Drumroll
please) im Journal.
Von dort kann man sie mit 'coredumpctl' auflisten/anzeigen und dergl. mehr (what
where they smoking ..?).
Ziemlich sicher, da es ein kleines Yocto-Linux ist.
15 Mar
15 Mar
4:05 p.m.
Also danke an euch, ich konnte das Rätsel lösen.
Der Tip die Einstellung ins tmp zu schreiben zeigte: alles ok.
Also musste es was anderes sein - banal!
Das Programm ist einfach nicht gecrasht, wie gedacht.
Ich hatte in eine lib einen Bug eingebaut, und mein Testprogamm hat
darauf reagiert, das Hauptprogramm nicht.
Also in dem Programm vom Script wurde das Signal abgefangen.
So blöd - entschuldigt. Ich war mir sicher ich hatte das probiert, aber ...
Schönes Wochenende
Arno
Am 14.03.2019 um 20:15 schrieb Ralf Mattes:
Am Donnerstag, 14. März 2019 19:17 CET, Arno <epsi(a)gmx.de> schrieb:
? Wirklich? Yocto-Linux "kann" beides, sysVinit oder systemd.
Falls Dein Linux wirklich systemd nutzt (Test: $ ps -q 1 -o comm= ) dann würde ich
schwer anraten
für Deinen Daemon ein Service-File anzulegen und nicht den
Initscript-Kompatibilitätsmodus zu nutzen.
Dann kannst Du auch dort direkt die Limits verändern (in Deinem Fall: LimitCORE=....).
Gruss RalfD
Mit diesem Befehl weise ich im gleichen Script, gleich neben dem ulimit
vorher den Platz und das Pattern zu, danach wird dann (ebenfalls im
gleichen Script) das chrashende binary aufgerufen.
Und das Pattern steht dann auch kontrollierbar drin, nur ulimit -c zeigt
0. :(
Dann zeig' uns doch mal Dein Script. Du testest den Rückgabewert von 'ulimit'
?
[...]
PAM hab ich nicht (bewußt). Ich hatte das ulimit
wie gesagt vorher im
/etc/profile - aber da wirkt es nur, wenn ich das binary manuell nach
einloggen aufrufe.
Wenn Du /etc/limits hast dann hast Du wahrscheinlich auch PAM, das ist nämlich die
Config für das pam_limits Modul.
[...]
Bist Du
sicher dass Du/Deine Herzensdistro nicht systemd benutzt? Der hat u.U. dann
den systemd-coredump installiert (das solltest Du aber in der Ausgabe der oben genannten
Shell Comands sehen - da steht dann so was wie '|/usr/lib/systemd/systemd-coredump %p
%u %g %s %t %e
'). Falls systemd da seine schmutzigen Hände drinn hat landen die Dumps (Drumroll
please) im Journal.
Von dort kann man sie mit 'coredumpctl' auflisten/anzeigen und dergl. mehr (what
where they smoking ..?).
Ziemlich sicher, da es ein kleines Yocto-Linux ist.
1871
days inactive
1872
days old
6 comments
4 participants
participants (4)
-
Arno -
Arno Steffens
-
Holger Klawitter -
Ralf Mattes