Bookworm friert nach Sicherheitsupdate regelmäßig ein

[Kermit24]

Siehe diese lange Zeile im syslog (in Code Darstellung schlecht lesbar)
2024-08-01T12:18:33.553829+02:00 nuc systemd-coredump[2391304]: Process 2156793 (Xorg) of user 0 dumped core.#012#012Module libsystemd.so.0 from deb systemd-252.26-1~deb12u2.amd64#012Module libudev.so.1 from deb systemd-252.26-1~deb12u2.amd64#012Stack trace of thread 2156793:#012#0 0x00007fbd2caa9e2c n/a (libc.so.6 + 0x8ae2c)#012#1 0x00007fbd2ca5afb2 raise (libc.so.6 + 0x3bfb2)#012#2 0x00007fbd2ca45472 abort (libc.so.6 + 0x26472)#012#3 0x0000559f968f9c4a OsAbort (Xorg + 0x1d5c4a)#012#4 0x0000559f968ff2b3 n/a (Xorg + 0x1db2b3)#012#5 0x0000559f969002e5 FatalError (Xorg + 0x1dc2e5)#012#6 0x0000559f968f6fc8 n/a (Xorg + 0x1d2fc8)#012#7 0x00007fbd2ca5b050 n/a (libc.so.6 + 0x3c050)#012#8 0x0000559f967ce1ac xf86ScreenToScrn (Xorg + 0xaa1ac)#012#9 0x00007fbd2c702082 n/a (modesetting_drv.so + 0x14082)#012#10 0x0000559f9686067c n/a (Xorg + 0x13c67c)#012#11 0x0000559f9685dc81 n/a (Xorg + 0x139c81)#012#12 0x0000559f9680d4e2 n/a (Xorg + 0xe94e2)#012#13 0x0000559f967aec4b n/a (Xorg + 0x8ac4b)#012#14 0x0000559f967b1a18 DeleteWindow (Xorg + 0x8da18)#012#15 0x0000559f967aa2fd n/a (Xorg + 0x862fd)#012#16 0x0000559f967ab51c FreeClientResources (Xorg + 0x8751c)#012#17 0x0000559f967ab5cb FreeAllResources (Xorg + 0x875cb)#012#18 0x0000559f9678788e n/a (Xorg + 0x6388e)#012#19 0x00007fbd2ca4624a n/a (libc.so.6 + 0x2724a)#012#20 0x00007fbd2ca46305 __libc_start_main (libc.so.6 + 0x27305)#012#21 0x0000559f96770b71 _start (Xorg + 0x4cb71)#012#012Stack trace of thread 2156799:#012#0 0x00007fbd2caa4e96 n/a (libc.so.6 + 0x85e96)#012#1 0x00007fbd2caa7558 pthread_cond_wait (libc.so.6 + 0x88558)#012#2 0x00007fbd2a70c059 n/a (iris_dri.so + 0x10c059)#012#3 0x00007fbd2a6be17b n/a (iris_dri.so + 0xbe17b)#012#4 0x00007fbd2a70bf97 n/a (iris_dri.so + 0x10bf97)#012#5 0x00007fbd2caa8134 n/a (libc.so.6 + 0x89134)#012#6 0x00007fbd2cb287dc n/a (libc.so.6 + 0x1097dc)#012#012Stack trace of thread 2156801:#012#0 0x00007fbd2caa4e96 n/a (libc.so.6 + 0x85e96)#012#1 0x00007fbd2caa7558 pthread_cond_wait (libc.so.6 + 0x88558)#012#2 0x00007fbd2a70c059 n/a (iris_dri.so + 0x10c059)#012#3 0x00007fbd2a6be17b n/a (iris_dri.so + 0xbe17b)#012#4 0x00007fbd2a70bf97 n/a (iris_dri.so + 0x10bf97)#012#5 0x00007fbd2caa8134 n/a (libc.so.6 + 0x89134)#012#6 0x00007fbd2cb287dc n/a (libc.so.6 + 0x1097dc)#012#012Stack trace of thread 2156800:#012#0 0x00007fbd2caa4e96 n/a (libc.so.6 + 0x85e96)#012#1 0x00007fbd2caa7558 pthread_cond_wait (libc.so.6 + 0x88558)#012#2 0x00007fbd2a70c059 n/a (iris_dri.so + 0x10c059)#012#3 0x00007fbd2a6be17b n/a (iris_dri.so + 0xbe17b)#012#4 0x00007fbd2a70bf97 n/a (iris_dri.so + 0x10bf97)#012#5 0x00007fbd2caa8134 n/a (libc.so.6 + 0x89134)#012#6 0x00007fbd2cb287dc n/a (libc.so.6 + 0x1097dc)#012#012Stack trace of thread 2156797:#012#0 0x00007fbd2caa4e96 n/a (libc.so.6 + 0x85e96)#012#1 0x00007fbd2caa7558 pthread_cond_wait (libc.so.6 + 0x88558)#012#2 0x00007fbd2a70c059 n/a (iris_dri.so + 0x10c059)#012#3 0x00007fbd2a6be17b n/a (iris_dri.so + 0xbe17b)#012#4 0x00007fbd2a70bf97 n/a (iris_dri.so + 0x10bf97)#012#5 0x00007fbd2caa8134 n/a (libc.so.6 + 0x89134)#012#6 0x00007fbd2cb287dc n/a (libc.so.6 + 0x1097dc)#012#012Stack trace of thread 2156798:#012#0 0x00007fbd2caa4e96 n/a (libc.so.6 + 0x85e96)#012#1 0x00007fbd2caa7558 pthread_cond_wait (libc.so.6 + 0x88558)#012#2 0x00007fbd2a70c059 n/a (iris_dri.so + 0x10c059)#012#3 0x00007fbd2a6be17b n/a (iris_dri.so + 0xbe17b)#012#4 0x00007fbd2a70bf97 n/a (iris_dri.so + 0x10bf97)#012#5 0x00007fbd2caa8134 n/a (libc.so.6 + 0x89134)#012#6 0x00007fbd2cb287dc n/a (libc.so.6 + 0x1097dc)#012#012Stack trace of thread 2156802:#012#0 0x00007fbd2caa4e96 n/a (libc.so.6 + 0x85e96)#012#1 0x00007fbd2caa7558 pthread_cond_wait (libc.so.6 + 0x88558)#012#2 0x00007fbd2a70c059 n/a (iris_dri.so + 0x10c059)#012#3 0x00007fbd2a6be17b n/a (iris_dri.so + 0xbe17b)#012#4 0x00007fbd2a70bf97 n/a (iris_dri.so + 0x10bf97)#012#5 0x00007fbd2caa8134 n/a (libc.so.6 + 0x89134)#012#6 0x00007fbd2cb287dc n/a (libc.so.6 + 0x1097dc)#012#012Stack trace of thread 2156803:#012#0 0x00007fbd2caa4e96 n/a (libc.so.6 + 0x85e96)#012#1 0x00007fbd2caa7558 pthread_cond_wait (libc.so.6 + 0x88558)#012#2 0x00007fbd2a70c059 n/a (iris_dri.so + 0x10c059)#012#3 0x00007fbd2a6be17b n/a (iris_dri.so + 0xbe17b)#012#4 0x00007fbd2a70bf97 n/a (iris_dri.so + 0x10bf97)#012#5 0x00007fbd2caa8134 n/a (libc.so.6 + 0x89134)#012#6 0x00007fbd2cb287dc n/a (libc.so.6 + 0x1097dc)#012#012Stack trace of thread 2156804:#012#0 0x00007fbd2caa4e96 n/a (libc.so.6 + 0x85e96)#012#1 0x00007fbd2caa7558 pthread_cond_wait (libc.so.6 + 0x88558)#012#2 0x00007fbd2a70c059 n/a (iris_dri.so + 0x10c059)#012#3 0x00007fbd2a6be17b n/a (iris_dri.so + 0xbe17b)#012#4 0x00007fbd2a70bf97 n/a (iris_dri.so + 0x10bf97)#012#5 0x00007fbd2caa8134 n/a (libc.so.6 + 0x89134)#012#6 0x00007fbd2cb287dc n/a (libc.so.6 + 0x1097dc)#012#012Stack trace of thread 2156812:#012#0 0x00007fbd2caa4e96 n/a (libc.so.6 + 0x85e96)#012#1 0x00007fbd2caa7558 pthread_cond_wait (libc.so.6 + 0x88558)#012#2 0x00007fbd2a70c059 n/a (iris_dri.so + 0x10c059)#012#3 0x00007fbd2a6be17b n/a (iris_dri.so + 0xbe17b)#012#4 0x00007fbd2a70bf97 n/a (iris_dri.so + 0x10bf97)#012#5 0x00007fbd2caa8134 n/a (libc.so.6 + 0x89134)#012#6 0x00007fbd2cb287dc n/a (libc.so.6 + 0x1097dc)#012#012Stack trace of thread 2156814:#012#0 0x00007fbd2caa4e96 n/a (libc.so.6 + 0x85e96)#012#1 0x00007fbd2caa7558 pthread_cond_wait (libc.so.6 + 0x88558)#012#2 0x00007fbd2a70c059 n/a (iris_dri.so + 0x10c059)#012#3 0x00007fbd2a6be17b n/a (iris_dri.so + 0xbe17b)#012#4 0x00007fbd2a70bf97 n/a (iris_dri.so + 0x10bf97)#012#5 0x00007fbd2caa8134 n/a (libc.so.6 + 0x89134)#012#6 0x00007fbd2cb287dc n/a (libc.so.6 + 0x1097dc)#012#012Stack trace of thread 2156820:#012#0 0x00007fbd2cb27e26 epoll_wait (libc.so.6 + 0x108e26)#012#1 0x0000559f968f78b7 n/a (Xorg + 0x1d38b7)#012#2 0x0000559f968f5091 n/a (Xorg + 0x1d1091)#012#3 0x00007fbd2caa8134 n/a (libc.so.6 + 0x89134)#012#4 0x00007fbd2cb287dc n/a (libc.so.6 + 0x1097dc)#012#012Stack trace of thread 2156809:#012#0 0x00007fbd2caa4e96 n/a (libc.so.6 + 0x85e96)#012#1 0x00007fbd2caa7558 pthread_cond_wait (libc.so.6 + 0x88558)#012#2 0x00007fbd2a70c059 n/a (iris_dri.so + 0x10c059)#012#3 0x00007fbd2a6be17b n/a (iris_dri.so + 0xbe17b)#012#4 0x00007fbd2a70bf97 n/a (iris_dri.so + 0x10bf97)#012#5 0x00007fbd2caa8134 n/a (libc.so.6 + 0x89134)#012#6 0x00007fbd2cb287dc n/a (libc.so.6 + 0x1097dc)#012#012Stack trace of thread 2156810:#012#0 0x00007fbd2caa4e96 n/a (libc.so.6 + 0x85e96)#012#1 0x00007fbd2caa7558 pthread_cond_wait (libc.so.6 + 0x88558)#012#2 0x00007fbd2a70c059 n/a (iris_dri.so + 0x10c059)#012#3 0x00007fbd2a6be17b n/a (iris_dri.so + 0xbe17b)#012#4 0x00007fbd2a70bf97 n/a (iris_dri.so + 0x10bf97)#012#5 0x00007fbd2caa8134 n/a (libc.so.6 + 0x89134)#012#6 0x00007fbd2cb287dc n/a (libc.so.6 + 0x1097dc)#012#012Stack trace of thread 2156811:#012#0 0x00007fbd2caa4e96 n/a (libc.so.6 + 0x85e96)#012#1 0x00007fbd2caa7558 pthread_cond_wait (libc.so.6 + 0x88558)#012#2 0x00007fbd2a70c059 n/a (iris_dri.so + 0x10c059)#012#3 0x00007fbd2a6be17b n/a (iris_dri.so + 0xbe17b)#012#4 0x00007fbd2a70bf97 n/a (iris_dri.so + 0x10bf97)#012#5 0x00007fbd2caa8134 n/a (libc.so.6 + 0x89134)#012#6 0x00007fbd2cb287dc n/a (libc.so.6 + 0x1097dc)#012#012Stack trace of thread 2156815:#012#0 0x00007fbd2caa4e96 n/a (libc.so.6 + 0x85e96)#012#1 0x00007fbd2caa7558 pthread_cond_wait (libc.so.6 + 0x88558)#012#2 0x00007fbd2a70c059 n/a (iris_dri.so + 0x10c059)#012#3 0x00007fbd2a6be17b n/a (iris_dri.so + 0xbe17b)#012#4 0x00007fbd2a70bf97 n/a (iris_dri.so + 0x10bf97)#012#5 0x00007fbd2caa8134 n/a (libc.so.6 + 0x89134)#012#6 0x00007fbd2cb287dc n/a (libc.so.6 + 0x1097dc)#012#012Stack trace of thread 2156813:#012#0 0x00007fbd2caa4e96 n/a (libc.so.6 + 0x85e96)#012#1 0x00007fbd2caa7558 pthread_cond_wait (libc.so.6 + 0x88558)#012#2 0x00007fbd2a70c059 n/a (iris_dri.so + 0x10c059)#012#3 0x00007fbd2a6be17b n/a (iris_dri.so + 0xbe17b)#012#4 0x00007fbd2a70bf97 n/a (iris_dri.so + 0x10bf97)#012#5 0x00007fbd2caa8134 n/a (libc.so.6 + 0x89134)#012#6 0x00007fbd2cb287dc n/a (libc.so.6 + 0x

[MSfree]

Siehe diese lange Zeile im syslog (in Code Darstellung schlecht lesbar)

Code: Alles auswählen

2024-08-01T12:18:33.553829+02:00 nuc systemd-coredump[2391304]: Process 2156793 (Xorg) of user 0 dumped core.

Da stürzt der Xserver ab.

Code: Alles auswählen

...(iris_dri.so + 0xbe17b)#012#4  0x00007fbd2a70bf97...

Und iris_dri.so ist für neuere Intel Graphiklösungen, z.B. Iris XE, zuständig.

Was mich wieder auf meinen Anfangspost mit dem falschen Treiber bringt. In vielen Fällen reicht es, die aktuellsten Firmwaredateien für die Intelgraphik zu installieren.

[mat6937]

Kann es ein Bug in der libc6 sein? Diese wurde ja aktualisiert bei dem besagten Update.

BTW: Das Problem das Du jetzt hast, hatte ich sofort nach der Neuinstallation von bookworm im Mai 2024, und konnte es durch die Konfiguration und Benutzung von systemd-oomd lösen.

Kann man oomd nicht so konfigurieren, dass es die Prozessliste mit Speicherverbrauch vor dem Killen loggt?

Das hat er doch gemacht. Siehe z. B. seine Ausgabe:

"" nuc systemd[1]: session-2565.scope: systemd-oomd killed some process(es) in this unit.
"" nuc systemd-oomd[2295032]: Considered 115 cgroups for killing, top candidates were:
"" nuc systemd-oomd[2295032]: #011Path: /user.slice/user-1001.slice/session-2565.scope
"" nuc systemd-oomd[2295032]: #011#011Swap Usage: 210.1M
"" nuc systemd-oomd[2295032]: #011Path: /system.slice/fhem.service
"" nuc systemd-oomd[2295032]: #011#011Swap Usage: 2.0M
"" nuc systemd-oomd[2295032]: #011Path: /system.slice/apache2.service
"" nuc systemd-oomd[2295032]: #011#011Swap Usage: 1.5M
"" nuc systemd-oomd[2295032]: #011Path: /system.slice/waydroid-container.service
"" nuc systemd-oomd[2295032]: #011#011Swap Usage: 1.4M
"" nuc systemd-oomd[2295032]: #011Path: /user.slice/user-1006.slice/session-5.scope
"" nuc systemd-oomd[2295032]: #011#011Swap Usage: 1.1M
"" nuc systemd-oomd[2295032]: #011Path: /system.slice/fail2ban.service
"" nuc systemd-oomd[2295032]: #011#011Swap Usage: 956.0K
"" nuc systemd-oomd[2295032]: #011Path: /init.scope
"" nuc systemd-oomd[2295032]: #011#011Swap Usage: 888.0K
"" nuc systemd-oomd[2295032]: #011Path: /system.slice/snapd.service
"" nuc systemd-oomd[2295032]: #011#011Swap Usage: 668.0K
"" nuc systemd-oomd[2295032]: #011Path: /system.slice/clamav-freshclam.service
"" nuc systemd-oomd[2295032]: #011#011Swap Usage: 648.0K
"" nuc systemd-oomd[2295032]: #011Path: /system.slice/ddclient.service
"" nuc systemd-oomd[2295032]: #011#011Swap Usage: 500.0K
"" nuc systemd-oomd[2295032]: Killed /user.slice/user-1001.slice/session-2565.scope due to memory
used (15878234112) / total (16647598080) and swap used (241889280) / total (268431360) being more than 90.00%

Die Frage ist, was veranlasst auf deinem System fhem, apache2, fail2ban, ddclient & Co. bei 16GB RAM, Swap-Speicher zu benutzen?

EDIT:

systemd-coredump ist per default nicht installiert. Hast Du systemd-coredump absichtlich installiert und aktiviert? Versuch mal temporär mit deaktiviertem systemd-coredump:

Code: Alles auswählen

systemctl stop systemd-coredump
systemctl disable systemd-coredump

[Kermit24]

Da stürzt der Xserver ab.
Und iris_dri.so ist für neuere Intel Graphiklösungen, z.B. Iris XE, zuständig.

Was mich wieder auf meinen Anfangspost mit dem falschen Treiber bringt. In vielen Fällen reicht es, die aktuellsten Firmwaredateien für die Intelgraphik zu installieren.

Sorry, vielleicht hast Du Recht. Die Intel Firmware Dateien hatte ich vorher allerdings auch nicht. Ich habe jetzt mal non-free-firmware in die /etc/apt/sources.list hinzugefügt und noch mal ein dist-upgrade durchgeführt, sowie 'apt install linux-firmware-nonfree'

dist-upgrade brachte mir nun u.a. wieder einen neuen Kernel und neue libc. Neugebootet und offensichtlich gibt es einen Unterschied:

syslog kernel von Anfang Juli:

Code: Alles auswählen

2024-07-07T06:50:51.626641+02:00 nuc kernel: [    1.944173] i915 0000:00:02.0: firmware: failed to load i915/kbl_dmc_ver1_04.bin (-2)
2024-07-07T06:50:51.626641+02:00 nuc kernel: [    1.944177] firmware_class: See https://wiki.debian.org/Firmware for information about missing firmware
2024-07-07T06:50:51.626642+02:00 nuc kernel: [    1.944185] i915 0000:00:02.0: firmware: failed to load i915/kbl_dmc_ver1_04.bin (-2)
2024-07-07T06:50:51.626648+02:00 nuc kernel: [    1.944189] i915 0000:00:02.0: Direct firmware load for i915/kbl_dmc_ver1_04.bin failed with error -2
2024-07-07T06:50:51.626649+02:00 nuc kernel: [    1.944191] i915 0000:00:02.0: [drm] Failed to load DMC firmware i915/kbl_dmc_ver1_04.bin. Disabling runtime power management.
2024-07-07T06:50:51.626650+02:00 nuc kernel: [    1.944192] i915 0000:00:02.0: [drm] DMC firmware homepage: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/i915
2024-07-07T06:50:51.685071+02:00 nuc NetworkManager[903]: <info>  [1720327851.6847] manager[0x55e4a343b000]: monitoring kernel firmware directory '/lib/firmware'.

syslog kernel von gerade eben:

Code: Alles auswählen

2024-08-01T20:34:51.392149+02:00 nuc kernel: [    2.123833] i915 0000:00:02.0: firmware: direct-loading firmware i915/kbl_dmc_ver1_04.bin
2024-08-01T20:34:51.392151+02:00 nuc kernel: [    2.124224] i915 0000:00:02.0: [drm] Finished loading DMC firmware i915/kbl_dmc_ver1_04.bin (v1.4)

DMC ist wohl Display Microcontroller. Ich vermute jedoch ,dass der nur für irgendwelche DRM-Sachen wichtig ist, sofern ich das richtig verstehe.

An der xorg.log hat sich jedenfalls vorher/nacher dadurch nichts verändert.

Kann man oomd nicht so konfigurieren, dass es die Prozessliste mit Speicherverbrauch vor dem Killen loggt?

Das hat er doch gemacht. Siehe z. B. seine Ausgabe:

"" nuc systemd[1]: session-2565.scope: systemd-oomd killed some process(es) in this unit.
"" nuc systemd-oomd[2295032]: Considered 115 cgroups for killing, top candidates were:
"" nuc systemd-oomd[2295032]: #011Path: /user.slice/user-1001.slice/session-2565.scope
"" nuc systemd-oomd[2295032]: #011#011Swap Usage: 210.1M
"" nuc systemd-oomd[2295032]: #011Path: /system.slice/fhem.service
"" nuc systemd-oomd[2295032]: #011#011Swap Usage: 2.0M
"" nuc systemd-oomd[2295032]: #011Path: /system.slice/apache2.service
"" nuc systemd-oomd[2295032]: #011#011Swap Usage: 1.5M
"" nuc systemd-oomd[2295032]: #011Path: /system.slice/waydroid-container.service
"" nuc systemd-oomd[2295032]: #011#011Swap Usage: 1.4M
"" nuc systemd-oomd[2295032]: #011Path: /user.slice/user-1006.slice/session-5.scope
"" nuc systemd-oomd[2295032]: #011#011Swap Usage: 1.1M
"" nuc systemd-oomd[2295032]: #011Path: /system.slice/fail2ban.service
"" nuc systemd-oomd[2295032]: #011#011Swap Usage: 956.0K
"" nuc systemd-oomd[2295032]: #011Path: /init.scope
"" nuc systemd-oomd[2295032]: #011#011Swap Usage: 888.0K
"" nuc systemd-oomd[2295032]: #011Path: /system.slice/snapd.service
"" nuc systemd-oomd[2295032]: #011#011Swap Usage: 668.0K
"" nuc systemd-oomd[2295032]: #011Path: /system.slice/clamav-freshclam.service
"" nuc systemd-oomd[2295032]: #011#011Swap Usage: 648.0K
"" nuc systemd-oomd[2295032]: #011Path: /system.slice/ddclient.service
"" nuc systemd-oomd[2295032]: #011#011Swap Usage: 500.0K
"" nuc systemd-oomd[2295032]: Killed /user.slice/user-1001.slice/session-2565.scope due to memory
used (15878234112) / total (16647598080) and swap used (241889280) / total (268431360) being more than 90.00%

Die Frage ist, was veranlasst auf deinem System fhem, apache2, fail2ban, ddclient & Co. bei 16GB RAM, Swap-Speicher zu benutzen?

EDIT:

systemd-coredump ist per default nicht installiert. Hast Du systemd-coredump absichtlich installiert und aktiviert? Versuch mal temporär mit deaktiviertem systemd-coredump:

Code: Alles auswählen

systemctl stop systemd-coredump
systemctl disable systemd-coredump

Das ist aber ja nur der Swap-Auszug und da sticht kein Prozess raus hervor. Ein Log vom RAM wie smem wäre da nicht verkehrt.

systemd-coredump habe ich absichtlich nicht installiert. Muss also eine Dep zu was anderem oder im Base-System schon drin gewesen sein.
systemd-coredump kennt systemd so nicht:

Code: Alles auswählen

systemctl stop systemd-coredump
Failed to stop systemd-coredump.service: Unit systemd-coredump.service not loaded.
systemctl disable systemd-coredump
Failed to disable unit: Unit file systemd-coredump.service does not exist.

systemctl stop systemd-coredump.socket
systemctl disable systemd-coredump.socket

[mat6937]

Das ist aber ja nur der Swap-Auszug und da sticht kein Prozess raus hervor. Ein Log vom RAM wie smem wäre da nicht verkehrt.

Für RAM-Speicherbelegung/Verbrauch kenne ich nur pmap mit Hilfe der PID:

Code: Alles auswählen

pmap -d <PID> | grep mapped

Z. B.:

Code: Alles auswählen

:~# pmap -d $(pgrep Xorg) | grep mapped
mapped: 498768K    writeable/private: 32152K    shared: 111808K

Code: Alles auswählen

systemctl stop systemd-coredump
Failed to stop systemd-coredump.service: Unit systemd-coredump.service not loaded.
systemctl disable systemd-coredump
Failed to disable unit: Unit file systemd-coredump.service does not exist.

Versuch mal mit:

Code: Alles auswählen

apt policy systemd-coredump
systemctl list-units --type=service | grep -i coredump

... und in der "coredump.conf"-Datei, mit:

Code: Alles auswählen

Storage=none
ProcessSizeMax=0

Quelle: https://manpages.debian.org/bookworm/sy ... processing

EDIT:

BTW: Es gibt kein "Hängt ab von:" bei

Code: Alles auswählen

:~$ apt rdepends systemd-coredump
systemd-coredump
Reverse Depends:
  Empfiehlt: drkonqi
  Schlägt vor: libflatpak-dev
  Schlägt vor: phosh-core
  Schlägt vor: libflatpak-dev

[Kermit24]

systemd-coredump wurde offensichtlich von plasma-desktop automatisch mitinstalliert (plasma-desktop->plasma-workspace->drkonqi->systemd-coredump).

Code: Alles auswählen

apt policy systemd-coredump
systemd-coredump:
  Installiert:           252.26-1~deb12u2
  Installationskandidat: 252.26-1~deb12u2
  Versionstabelle:
     254.16-1~bpo12+1 100
        100 http://deb.debian.org/debian bookworm-backports/main amd64 Packages
 *** 252.26-1~deb12u2 500
        500 http://deb.debian.org/debian bookworm/main amd64 Packages
        100 /var/lib/dpkg/status
        
systemctl list-units --type=service | grep -i coredump

Letzter Befehl gibt nichts zurück.

Ich habe die /etc/systemd/coredump.conf mal angepasst, auch wenn drinsteht, dass man es nicht tun soll, weil es nicht lange bestand hat (sondern wieder nur über drop-ins aus coredump.conf.d/ welches wieder nicht exisitert). "systemctl edit --full systemd-coredump" funktioniert nicht, weil systemd-coredump nicht bekannt ist (s.o.)

Code: Alles auswählen

systemctl edit --full systemd-coredump
No files found for systemd-coredump.service.
Run 'systemctl edit --force --full systemd-coredump.service' to create a new unit.

Ich habe deshalb auch keine Ahnung, wie ich systemd-coredump neustarten, bzw. ein reload der .conf durchführen kann.

[mat6937]

Letzter Befehl gibt nichts zurück.

Ich habe die /etc/systemd/coredump.conf mal angepasst, auch wenn drinsteht, dass man es nicht tun soll, weil es nicht lange bestand hat (sondern wieder nur über drop-ins aus coredump.conf.d/ welches wieder nicht exisitert). "systemctl edit --full systemd-coredump" funktioniert nicht, weil systemd-coredump nicht bekannt ist (s.o.)

Code: Alles auswählen

systemctl edit --full systemd-coredump
No files found for systemd-coredump.service.
Run 'systemctl edit --force --full systemd-coredump.service' to create a new unit.

Ich habe deshalb auch keine Ahnung, wie ich systemd-coredump neustarten, bzw. ein reload der .conf durchführen kann.

Was hast Du mit "systemctl edit --full systemd-coredump" in der service-unit ändern wollen?
Es kann auch sein, dass die Änderung/Ergänzung in der /etc/systemd/coredump.conf-Datei, nur über die socket-unit (systemd-coredump.socket) berücksichtigt bzw. benutzt wird.

EDIT:

Wenn die service-unit für coredump (in der Form) nicht vorhanden ist, wird das schon seine Richtigkeit haben, ... so dass diese nicht angelegt/erstellt werden muss.

[MSfree]

systemd-coredump wurde offensichtlich von plasma-desktop automatisch mitinstalliert (plasma-desktop->plasma-workspace->drkonqi->systemd-coredump). ...

Was willst du denn mit den Coredumps?

Für Endanwender sind diese Dumps ziemlich unergiebig.

[Kermit24]

Ich will nichts mit coredump. Aber kde plasma probiere ich gelegentlich mal (genauso wie xfce), bzw. nutze fast täglich einige Anwendungen daraus. Am Ende lande ich aber doch wieder bei lxde, weil mir einfach irgendwas fehlt.

Will ich coredump deinstallieren, werde ich rot angemeckert: "Die folgenden Empfehlungen unaufgelöst lassen: drkonqi empfiehlt systemd-coredump"

Und empfehlungen folge ich, bzw. apt eigentlich immer, weil sonst ja Applikationen u.U. nur eingeschränkt funktionieren.

Aber sei's drum:

Code: Alles auswählen

apt remove systemd-coredump 
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
Die folgenden Pakete werden ENTFERNT:
  systemd-coredump
0 aktualisiert, 0 neu installiert, 1 zu entfernen und 0 nicht aktualisiert.
Nach dieser Operation werden 259 kB Plattenplatz freigegeben.
Möchten Sie fortfahren? [J/n] j
(Lese Datenbank ... 630599 Dateien und Verzeichnisse sind derzeit installiert.)
Entfernen von systemd-coredump (252.26-1~deb12u2) ...
Trigger für man-db (2.11.2-2) werden verarbeitet ...

[mat6937]

... drkonqi empfiehlt systemd-coredump"

Evtl. mit "--no-install-recommends --no-install-suggests" installieren (bzw. apt dafür benutzen).

[Kermit24]

Wir waren im Urlaub und sind gerade den 2.Tag wieder da. Und schon zerreißt es mir die X11-Session wieder:

Code: Alles auswählen

2024-08-13T09:24:53.881910+02:00 nuc systemd[1]: session-5.scope: systemd-oomd killed some process(es) in this unit.
2024-08-13T09:24:53.888232+02:00 nuc systemd-oomd[748]: Considered 113 cgroups for killing, top candidates were:
2024-08-13T09:24:53.889840+02:00 nuc systemd-oomd[748]: #011Path: /user.slice/user-1001.slice/session-5.scope
2024-08-13T09:24:53.890950+02:00 nuc systemd-oomd[748]: #011#011Swap Usage: 184.7M
2024-08-13T09:24:53.891025+02:00 nuc systemd-oomd[748]: #011Path: /user.slice/user-1001.slice/user@1001.service/session.slice/gvfs-metadata.service
2024-08-13T09:24:53.891076+02:00 nuc systemd-oomd[748]: #011#011Swap Usage: 36.3M
2024-08-13T09:24:53.891361+02:00 nuc systemd-oomd[748]: #011Path: /system.slice/lightdm.service
2024-08-13T09:24:53.891430+02:00 nuc systemd-oomd[748]: #011#011Swap Usage: 7.6M
2024-08-13T09:24:53.891812+02:00 nuc systemd-oomd[748]: #011Path: /system.slice/asterisk.service
2024-08-13T09:24:53.891876+02:00 nuc systemd-oomd[748]: #011#011Swap Usage: 3.3M
2024-08-13T09:24:53.891936+02:00 nuc systemd-oomd[748]: #011Path: /system.slice/fhem.service
2024-08-13T09:24:53.891996+02:00 nuc systemd-oomd[748]: #011#011Swap Usage: 2.1M
2024-08-13T09:24:53.892084+02:00 nuc systemd-oomd[748]: #011Path: /user.slice/user-1001.slice/user@1001.service/session.slice/gvfs-daemon.service
2024-08-13T09:24:53.892138+02:00 nuc systemd-oomd[748]: #011#011Swap Usage: 2.0M
2024-08-13T09:24:53.892183+02:00 nuc systemd-oomd[748]: #011Path: /system.slice/waydroid-container.service
2024-08-13T09:24:53.892512+02:00 nuc systemd-oomd[748]: #011#011Swap Usage: 1.3M
2024-08-13T09:24:53.892573+02:00 nuc systemd-oomd[748]: #011Path: /system.slice/apache2.service
2024-08-13T09:24:53.892625+02:00 nuc systemd-oomd[748]: #011#011Swap Usage: 1.2M
2024-08-13T09:24:53.892682+02:00 nuc systemd-oomd[748]: #011Path: /user.slice/user-1001.slice/user@1001.service/session.slice/pipewire-pulse.service
2024-08-13T09:24:53.892978+02:00 nuc systemd-oomd[748]: #011#011Swap Usage: 984.0K
2024-08-13T09:24:53.893085+02:00 nuc systemd-oomd[748]: #011Path: /user.slice/user-1001.slice/user@1001.service/session.slice/pipewire.service
2024-08-13T09:24:53.893190+02:00 nuc systemd-oomd[748]: #011#011Swap Usage: 844.0K
2024-08-13T09:24:53.893295+02:00 nuc systemd-oomd[748]: Killed /user.slice/user-1001.slice/user@1001.service/session.slice/gvfs-metadata.service due to memory used (16518610944) / total (16647593984) and swap used (268431360) / total (268431360) being more than 90.00%
2024-08-13T09:24:53.908250+02:00 nuc systemd[4158]: gvfs-metadata.service: systemd-oomd killed 3 process(es) in this unit.
2024-08-13T09:24:53.923135+02:00 nuc systemd[4158]: gvfs-metadata.service: Main process exited, code=killed, status=9/KILL
2024-08-13T09:24:53.924200+02:00 nuc systemd[4158]: gvfs-metadata.service: Failed with result 'oom-kill'.
2024-08-13T09:24:53.924931+02:00 nuc systemd[4158]: gvfs-metadata.service: Consumed 5.917s CPU time.
2024-08-13T09:24:53.976495+02:00 nuc at-spi-bus-launcher[4331]: X connection to :0 broken (explicit kill or server shutdown).
2024-08-13T09:24:53.987696+02:00 nuc kglobalaccel5[56612]: The X11 connection broke (error 1). Did the X11 server die?
2024-08-13T09:24:53.988185+02:00 nuc kactivitymanagerd[56601]: The X11 connection broke (error 1). Did the X11 server die?
2024-08-13T09:24:53.990633+02:00 nuc xdg-desktop-portal-kde[4547]: The X11 connection broke (error 1). Did the X11 server die?

Ich bin langsam echt ratlos. Seit April 2019 lief der nuc8 mit Debian fehlerfrei. Und genau seit besagten Update die Probleme. Ich war gerade wieder auf einer heise.de Webseite unterwegs, als der Fehler auftrat. Dort passiert es gefühlt sehr häufig (bin vielleicht max. 30min/Tag dort unterwegs), insbesondere zu anfang - und da mit zwei verschiedenen Browsern!

Ich werde wohl die Woche mal die 64GB Ram einbauen. Nach einem Arbeitsspeicherfehler sieht das allerdings nicht aus. Insofern werde ich nicht stundenlang memtest86 laufen lassen, zumal ich ja Ersatz-Ram hier liegen habe.

Kann man oomd nicht sagen, dass er erst mal nur 1Prozess abschießen soll statt direkt 3? Hier sticht ja mal gvfs-metadata.service heraus.

[user8111]

Installiere doch bitte mal den neueren Kernel aus den Backports. Würde mich nicht wundern, wenn der das Problem behebt.

Code: Alles auswählen

deb http://ftp.debian.org/debian/ bookworm-backports main contrib non-free 

zu /etc/apt/sources.list hinzufügen

und dann

Code: Alles auswählen

apt-get update
apt-get install -t bookworm-backports linux-image-amd64 linux-headers-amd64

[Kermit24]

Danke für den Tipp! Nachdem ich den Fehler in der letzten Woche 4x hatte und oom_killer immer andere Prozesse willkürlich killt, habe ich jetzt mal den Kernel aus den Backports genommen:

uname -a
Linux nuc 6.10.6+bpo-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.10.6-1~bpo12+1 (2024-08-26) x86_64 GNU/Linux

außerdem meldete update-initramfs bei der aktualisierung 5 fehlende i915 Firmware-Dateien. Die habe ich nicht im repository gefunden und deshalb per Hand von hier https://git.kernel.org/pub/scm/linux/ke ... mware.git/ nach /lib/firmware/i915 kopiert.

Werde jetzt mal weiter beobachten und hoffe immer noch, dass der Spuk endlich mal ein Ende hat.

Nachtrag: Wieder nichts: Heute 3 Firefox-Tabs im heise Forum offen und oom-killer war wieder aktiv. Kann doch nicht sein, dass 16GB zuwenig für debian ist. Ich habe jetzt systematisch alle externen Apps (nicht aus dem repository) ausgeschlossen, indem ich sie mal einige Tage nicht laufen hatte: Der Messenger Wire und Syncthing kann ich somit als Übeltäter auch ausschließen. Sonst nutze ich eigentlich keine fremden Pakete/Programme