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
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
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
Am Donnerstag, 14. März 2019 14:16 CET, "Arno Steffens" epsi@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
Am 14.03.2019 um 17:35 schrieb Ralf Mattes:
Am Donnerstag, 14. März 2019 14:16 CET, "Arno Steffens" epsi@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
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. :(
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.
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.
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 ..?).
Ziemlich sicher, da es ein kleines Yocto-Linux ist. Vielen Dank trotzdem für den Input.
Gruss RalfD
Gruß Arno
Am Donnerstag, 14. März 2019 19:17 CET, Arno epsi@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. :(
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.
? 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
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@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. :(
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.
? 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
-
Arno -
Arno Steffens
-
Holger Klawitter -
Ralf Mattes