Moin,
ich habe ein RH8 System und will beeinflussen, wo (potentielle) Core Dumps abgelegt werden. Nach einigem Herumsurfen komme ich zu dem Ergebnis, daß diese auch mit systemd über den Kernel-Parameter "kernel.core_pattern" gesteuert wird:
kernel.core_pattern = |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h %e
Von hier aus lande ich bei [1], finde aber nicht die Stelle, wo man die Lokation des Core Dumps steuern kann (außer natürlich "kernel.core_pattern" selber anpassen).
Habe ich was verpennt?
Hilmar
[1] https://www.man7.org/linux/man-pages/man8/systemd-coredump.8.html
Hallo Hilmar,
On Sun, Dec 29, 2024 at 23:49:29 +0100, Preuße, Hilmar wrote:
ich habe ein RH8 System und will beeinflussen, wo (potentielle) Core Dumps abgelegt werden. Nach einigem Herumsurfen komme ich zu dem Ergebnis, daß diese auch mit systemd über den Kernel-Parameter "kernel.core_pattern" gesteuert wird:
kernel.core_pattern = |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h %e
Von hier aus lande ich bei [1], finde aber nicht die Stelle, wo man die Lokation des Core Dumps steuern kann (außer natürlich "kernel.core_pattern" selber anpassen).
Die Manpage systemd-coredump(8) verweist auf coredump.conf(5). Dort gibt es in der Section [Coredump] das Setting Storage=... Damit sollte es konfigurierbar sein.
Der sysctl kernel.core_pattern hat ueber die Jahre immer mehr Features bekommen. Zuerst kam core_uses_pid dazu, dann Format Strings, dann die Moeglichkeit fuer einen optionalen Coredump-Helper im Userspace.
Grundsaetzlich unterscheidet der Kernel beim sysctl kernel.core_pattern zwischen Strings, die mit dem Pipe-Symbol beginnen und solchen, die einen absoluten oder relativen Pfad fuer den Core-Dateinamen beschreiben. Klassisches UN*X-Verhalten ist, dass der Kernel selbst eine Coredump-Datei "core" ins Working Directory des betreffenden Prozesses schreibt, sofern fuer den Owner des Prozesses die Berechtigungen ausreichen.
Beim Pipe-Symbol wird der nachfolgende Pfad vom Kernel als der eines Executables (Binary oder Skript) interpretiert. Tritt ein Coredump auf, startet der Kernel via call_usermodehelper() das Executable und schiebt die Coredump-Daten in dessen Standard Input. Was das Executable mit diesen Daten macht, geht den Kernel nichts mehr an.
Gruesse, Christian
On 30.12.2024 13:03, Christian Perle wrote:
On Sun, Dec 29, 2024 at 23:49:29 +0100, Preuße, Hilmar wrote:
Moin,
ich habe ein RH8 System und will beeinflussen, wo (potentielle) Core Dumps abgelegt werden. Nach einigem Herumsurfen komme ich zu dem Ergebnis, daß diese auch mit systemd über den Kernel-Parameter "kernel.core_pattern" gesteuert wird:
kernel.core_pattern = |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h %e
Von hier aus lande ich bei [1], finde aber nicht die Stelle, wo man die Lokation des Core Dumps steuern kann (außer natürlich "kernel.core_pattern" selber anpassen).
Die Manpage systemd-coredump(8) verweist auf coredump.conf(5). Dort gibt es in der Section [Coredump] das Setting Storage=... Damit sollte es konfigurierbar sein.
AFAICT leider nicht. [1] sagt:
Storage= Controls where to store cores. One of "none", "external", and "journal". When "none", the core dumps may be logged (including the backtrace if possible), but not stored permanently. When "external" (the default), cores will be stored in /var/lib/systemd/coredump/. When "journal", cores will be stored in the journal and rotated following normal journal rotation patterns.
Ich kann also nur festlegen, daß es nicht ins Journal soll, nicht aber wo konkret hin.
Der sysctl kernel.core_pattern hat ueber die Jahre immer mehr Features bekommen. Zuerst kam core_uses_pid dazu, dann Format Strings, dann die Moeglichkeit fuer einen optionalen Coredump-Helper im Userspace.
Grundsaetzlich unterscheidet der Kernel beim sysctl kernel.core_pattern zwischen Strings, die mit dem Pipe-Symbol beginnen und solchen, die einen absoluten oder relativen Pfad fuer den Core-Dateinamen beschreiben. Klassisches UN*X-Verhalten ist, dass der Kernel selbst eine Coredump-Datei "core" ins Working Directory des betreffenden Prozesses schreibt, sofern fuer den Owner des Prozesses die Berechtigungen ausreichen.
Vielen Dank für die Erläuterungen, aber das war mir schon alles klar. Hätte ich ggf. dazu schreiben sollen, sorry! Wenn man im core_pattern auf ein Pipe Zeichen trifft, wundert man sich als Erstes, was das zu sagen hat und wird neugierig.
Hilmar
[1] https://www.man7.org/linux/man-pages/man5/coredump.conf.5.html
Hallo Hilmar,
Diesen Disclaimer hatte ich vergessen :) Ich nutze von systemd nur so viel, wie mir Debian minimal vorsetzt.
On Tue, Dec 31, 2024 at 00:09:12 +0100, Preuße, Hilmar wrote:
Storage=
[...]
Ich kann also nur festlegen, daß es nicht ins Journal soll, nicht aber wo konkret hin.
Argh, das hatte ich ueberlesen. Da hat der Herr Poettering mal wieder entschieden, dass es so sein muss und nicht anders. Muss man nicht gut finden.
Man koennte jetzt /var/lib/systemd/coredump per Bind-Mount auf ein weiteres Verzeichnis mounten, aber das waere nur ein Hack.
Guten Rutsch, Christian
On 31.12.2024 10:11, Christian Perle wrote:
Moin,
Man koennte jetzt /var/lib/systemd/coredump per Bind-Mount auf ein weiteres Verzeichnis mounten, aber das waere nur ein Hack.
Das klingt zumindest nach einer Lösung. Letzte Frage: ich habs so probiert:
[root@sun10-2 ~]# cat /etc/fstab.d/core.fstab /appl/smile/core /var/lib/systemd/coredump none bind
, aber der Inhalt von /etc/fstab.d wird wohl (wieder) ignoriert. Muß ich wohl doch die fstab anfassen, oder?
H.
P.S.: Bitte nicht vom Rechnernamen verwirren lassen, das ist eine Rocky8.
Hallo Hilmar,
On Tue, Dec 31, 2024 at 11:09:12 +0100, Preuße, Hilmar wrote:
Das klingt zumindest nach einer Lösung. Letzte Frage: ich habs so probiert:
[root@sun10-2 ~]# cat /etc/fstab.d/core.fstab /appl/smile/core /var/lib/systemd/coredump none bind
Die Reihenfolge ist umgekehrt: Ins erste Feld muss die Quelle /var/lib/systemd/coredump, ins zweite der Mountpoint /appl/smile/core
Folgender Beispieleintrag hat hier funktioniert (allerdings in /etc/fstab eingetragen):
/home/images /var/spool/libreoffice none bind 0 0
Gruss, Christian
On 31.12.2024 11:50, Christian Perle wrote:
On Tue, Dec 31, 2024 at 11:09:12 +0100, Preuße, Hilmar wrote:
Hallo Christian,
Das klingt zumindest nach einer Lösung. Letzte Frage: ich habs so probiert:
[root@sun10-2 ~]# cat /etc/fstab.d/core.fstab /appl/smile/core /var/lib/systemd/coredump none bind
Die Reihenfolge ist umgekehrt: Ins erste Feld muss die Quelle /var/lib/systemd/coredump, ins zweite der Mountpoint /appl/smile/core
Na dann wars doch richtig: ich will ja ein größeres Filesystem (oder ein Subdir auf einem größeren FS) nach /var/lib/systemd/coredump mounten um dort größere Coredumps "ablegen" zu können, ohne daß /var voll läuft.
Momentan sieht es so aus:
[root@sun10-2 core]# mount|grep test /dev/mapper/test_bind_mount-lv--test on /appl type ext4 (rw,relatime,seclabel) /dev/mapper/test_bind_mount-lv--test on /var/lib/systemd/coredump type ext4 (rw,relatime,seclabel) [root@sun10-2 core]# df -h|grep test /dev/mapper/test_bind_mount-lv--test 3.9G 1.5G 2.3G 40% /appl [root@sun10-2 core]# ls -l /var/lib/systemd/coredump total 1500004 -rw-r--r--. 1 root root 1536000000 Dec 31 05:25 a [root@sun10-2 core]# ls -l /appl/smile/core total 1500004 -rw-r--r--. 1 root root 1536000000 Dec 31 05:25 a
Folgender Beispieleintrag hat hier funktioniert (allerdings in /etc/fstab eingetragen):
/home/images /var/spool/libreoffice none bind 0 0
Das war mein Punkt: ich würde gerne den Bind-Mount erreichen ohne die /etc/fstab anzufassen. Diese Datei ist hinreichend fragil und wird ggf. auch von anderen Gruppen verändert, so daß ich gerne um das File einen Bogen machen würde.
Ich habe erstmal eine systemunit gebaut/bauen lassen.
[root@sun10-2 system]# less -X /etc/systemd/system/var-lib-systemd-coredump.mount # Automatically generated by systemd-fstab-generator
[Unit] SourcePath=/etc/fstab Documentation=man:fstab(5) man:systemd-fstab-generator(8) Before=local-fs.target
[Mount] Where=/var/lib/systemd/coredump What=/appl/smile/core Type=none Options=bind
Leider klappt der Mount beim Reboot noch nicht. Erst nach "systemctl start /var/lib/systemd/coredump" is der Mount da.
H.
Hallo Hilmar,
Am 31.12.24 um 12:18 schrieb Preuße, Hilmar:
Ich habe erstmal eine systemunit gebaut/bauen lassen.
[root@sun10-2 system]# less -X /etc/systemd/system/var-lib-systemd- coredump.mount
...
Leider klappt der Mount beim Reboot noch nicht. Erst nach "systemctl start /var/lib/systemd/coredump" is der Mount da.
Hast du den mit "systemctl enable coredump.mount" schon aktiviert, damit er beim booten automatisch startet?
Und das erklärt vielleicht, warum das mit /etc/fstab.d/ nicht funktioniert: https://askubuntu.com/questions/168290/why-cant-mount-read-files-in-etc-fsta...
Gruß Rico
On 31.12.2024 15:51, Rico Koerner wrote:
Am 31.12.24 um 12:18 schrieb Preuße, Hilmar:
Moin,
Ich habe erstmal eine systemunit gebaut/bauen lassen.
[root@sun10-2 system]# less -X /etc/systemd/system/var-lib-systemd- coredump.mount
...
Leider klappt der Mount beim Reboot noch nicht. Erst nach "systemctl start /var/lib/systemd/coredump" is der Mount da.
Hast du den mit "systemctl enable coredump.mount" schon aktiviert, damit er beim booten automatisch startet?
Hatte ich probiert, klappt aber nicht:
[root@sun10-2 ~]# systemctl enable var-lib-systemd-coredump.mount The unit files have no installation config (WantedBy, RequiredBy, Also, Alias settings in the [Install] section, and DefaultInstance for template units). This means they are not meant to be enabled using systemctl. <snip>
Da hatte ich mangels Zeit noch nicht weiter getestet.
Und das erklärt vielleicht, warum das mit /etc/fstab.d/ nicht funktioniert: https://askubuntu.com/questions/168290/why-cant-mount- read-files-in-etc-fstab-d
Den hatte ich gesehen. Das util-linux auf der redhat ist aber aktuell genug:
[root@sun10-2 ~]# rpm -qa|grep util-linux util-linux-2.32.1-46.el8.x86_64 util-linux-user-2.32.1-46.el8.x86_64
Mich deucht der Support dafür wurde später wieder entfernt, bzw. in systemd nie eingeführt [1] & [2]. Darum suche ich jetzt nach anderen Lösungen, wie die systemd Unit von oben.
Ich habe erstmal geug zum Denken, bitte keine weiteren Vorschläge.
Ich wünsch Euch allen einen guten Rutsch und ein gesundes Neues!
Hilmar
[1] https://github.com/systemd/systemd/issues/12506 [2] https://github.com/util-linux/util-linux/issues/2559
Hallo Hilmar,
Am 31.12.24 um 16:10 schrieb Preuße, Hilmar:
Hatte ich probiert, klappt aber nicht:
[root@sun10-2 ~]# systemctl enable var-lib-systemd-coredump.mount The unit files have no installation config (WantedBy, RequiredBy, Also, Alias settings in the [Install] section, and DefaultInstance for template units). This means they are not meant to be enabled using systemctl.
<snip>
Da hatte ich mangels Zeit noch nicht weiter getestet.
Konservativ wäre: [Install] WantedBy=multi-user.target
sofern dir der Zeitpunkt dafür nicht zu spät ist.
Logisch klingt für mich auch: WantedBy=local-fs.target
Das widerspricht sich aber mit dem: [Unit] Before=local-fs.target
ggf. in Kombination mit: [Unit] After=basic.target
Dadurch dürfte sichergestellt sein, daß /var gemountet ist.
Gruß Rico
On 31.12.2024 18:45, Rico Koerner wrote:
Hallo Rico,
Logisch klingt für mich auch: WantedBy=local-fs.target
Das widerspricht sich aber mit dem: [Unit] Before=local-fs.target
Nun, ich habe das generierte Unit File einfach nur kopiert, weil ich selber mit systemd noch fremdele. Habe also das Before Statement entfernt und jetzt sieht die Unit so aus:
[root@sun10-2 core]# cat /etc/systemd/system/var-lib-systemd-coredump.mount # Automatically generated by systemd-fstab-generator
[Unit] SourcePath=/etc/fstab Documentation=man:fstab(5) man:systemd-fstab-generator(8)
[Mount] Where=/var/lib/systemd/coredump What=/appl/smile/core Type=none Options=bind
[Install] WantedBy=local-fs.target
Die läßt sich auch enablen und nach dem Reboot sind die mounts so, wie sie sein sollen.
Vielen Dank, Threadende. Danke an alle Beteiligten!
Hilmar
Hallo Hilmar,
Am 29.12.24 um 23:49 schrieb Preuße, Hilmar:
ich habe ein RH8 System
Du meinst hoffentlich RHEL8. RHL8 ist seit 2004 abgekündigt ...
Welche Version genau?
und will beeinflussen, wo (potentielle) Core Dumps abgelegt werden. Nach einigem Herumsurfen
Ich hoffe, du hast immer schön darauf geachtet, dass die Dokumentation, die du gefunden hast, zu deinem System passt, denn RHEL hat ja nicht die neueste Version von systemd und anderen Tools.
komme ich zu dem Ergebnis, daß diese auch mit systemd über den Kernel-Parameter "kernel.core_pattern" gesteuert wird:
kernel.core_pattern = |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h %e
Von hier aus lande ich bei [1], finde aber nicht die Stelle, wo man die Lokation des Core Dumps steuern kann (außer natürlich "kernel.core_pattern" selber anpassen).
Schau lieber in die Manpage deines Systems, dann ist einigermaßen sichergestellt, dass die Angaben dort auch zu der installierten Software passen.
Das wären erst mal die Grundlagen. Ihr seid ja im Thread schon etwas weitergekommen, wenn ich auch die ganze Zeit das Gefühl habe, dass die Antworten und Versuche an der Wirklichkeit von RHEL8 vorbeigehen.
Gruß Uwe
On 31.12.2024 16:19, Uwe Koloska wrote:
Am 29.12.24 um 23:49 schrieb Preuße, Hilmar:
Moin,
Danke für Deine Hinweise.
ich habe ein RH8 System
Du meinst hoffentlich RHEL8. RHL8 ist seit 2004 abgekündigt ...
Welche Version genau?
Eigentlich ein Rocky8.
[hille@sun10-2 ~]$ cat /etc/os-release NAME="Rocky Linux" VERSION="8.10 (Green Obsidian)" ID="rocky" ID_LIKE="rhel centos fedora" VERSION_ID="8.10" <snip>
und will beeinflussen, wo (potentielle) Core Dumps abgelegt werden. Nach einigem Herumsurfen
Ich hoffe, du hast immer schön darauf geachtet, dass die Dokumentation, die du gefunden hast, zu deinem System passt, denn RHEL hat ja nicht die neueste Version von systemd und anderen Tools.
Nun, ich hatte erstmal die Doku genutzt, die mir Duckduckgo verraten hat. Nachdem nicht mal dort (und die war aktueller als die für den systemd in RH8) etwas zum Thema "Lokation ändern" zu finden war, hatte ich gefragt.
komme ich zu dem Ergebnis, daß diese auch mit systemd über den Kernel- Parameter "kernel.core_pattern" gesteuert wird:
kernel.core_pattern = |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h %e
Von hier aus lande ich bei [1], finde aber nicht die Stelle, wo man die Lokation des Core Dumps steuern kann (außer natürlich "kernel.core_pattern" selber anpassen).
Schau lieber in die Manpage deines Systems, dann ist einigermaßen sichergestellt, dass die Angaben dort auch zu der installierten Software passen.
Wie gesagt: nicht mal aktuellere Versionen von systemd schreiben etwas dazu, darum sucht ich entweder Lücken in der Doku oder andere Ideen.
Das wären erst mal die Grundlagen. Ihr seid ja im Thread schon etwas weitergekommen, wenn ich auch die ganze Zeit das Gefühl habe, dass die Antworten und Versuche an der Wirklichkeit von RHEL8 vorbeigehen.
Die Wirklichkeit von RHEL8 lautet wohl "wenn Du nicht willst, daß /var bei Coredumps voll läuft, mounte halt ein neues FS an /var/lib/systemd/coredump an". Aber eigentlich sehe ich gar nicht ein, warum ich hier nochmal 10GB Plattenplatz spendieren soll, wenn woanders schon 100GB (relativ ungenutzt) herum liegen. Darum die Idee im Fall eines Crashs einfach woanders hin zu Dumpen.
Hilmar
On Sat 04.01.2025 00:26:19, Preuße, Hilmar wrote:
Die Wirklichkeit von RHEL8 lautet wohl "wenn Du nicht willst, daß /var bei Coredumps voll läuft, mounte halt ein neues FS an /var/lib/systemd/coredump an". Aber eigentlich sehe ich gar nicht ein, warum ich hier nochmal 10GB Plattenplatz spendieren soll, wenn woanders schon 100GB (relativ ungenutzt) herum liegen. Darum die Idee im Fall eines Crashs einfach woanders hin zu Dumpen.
Was nicht in der Anleitung steht: in dem "neuen FS" ist das "neue" optional:
mount -o bind /mnt/bigDisk/crashdumps /var/lib/systemd/coredump
und du kannst das große Filesystem benutzen. Und das geht natürlich auch persistent über die fstab.
Grüße, Andre
On 13.01.2025 21:09, Andre Klärner wrote:
Moin,
Was nicht in der Anleitung steht: in dem "neuen FS" ist das "neue" optional:
mount -o bind /mnt/bigDisk/crashdumps /var/lib/systemd/coredump
und du kannst das große Filesystem benutzen. Und das geht natürlich auch persistent über die fstab.
Wie schon erwähnt, wollte ich es vermeiden die /etc/fstab anzugreifen, weil dieses File auch von anderen Gruppen verändert wird und ich habe die Befürchtung, daß da einfach mal eine Zeile verschwindet, die für uns wichtig ist. Deswegen die Frage nach einem fstab Schnipsel in einem separaten File.
H.
lug-dd@mailman.schlittermann.de
-
Andre Klärner -
Christian Perle -
Preuße, Hilmar -
Rico Koerner -
Uwe Koloska