debianforum.de

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

Kermit24 hat geschrieben:

01.08.2024 12:32:26

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.

Kermit24 hat geschrieben:

01.08.2024 12:26:24

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.

Kermit24 hat geschrieben:

01.08.2024 12:26:24

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:

MSfree hat geschrieben:

01.08.2024 13:29:01

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: syslog kernel von gerade eben:

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.

mat6937 hat geschrieben:

01.08.2024 14:56:28

Kermit24 hat geschrieben:

01.08.2024 12:26:24

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:

Kermit24 hat geschrieben:

01.08.2024 21:20:55

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: Z. B.:

Kermit24 hat geschrieben:

01.08.2024 21:20:55

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: ... und in der "coredump.conf"-Datei, mit: Quelle: https://manpages.debian.org/bookworm/sy ... processing

EDIT:

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

systemd-coredump wurde offensichtlich von plasma-desktop automatisch mitinstalliert (plasma-desktop->plasma-workspace->drkonqi->systemd-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.) Ich habe deshalb auch keine Ahnung, wie ich systemd-coredump neustarten, bzw. ein reload der .conf durchführen kann.

Kermit24 hat geschrieben:

02.08.2024 12:11:49

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.

Kermit24 hat geschrieben:

02.08.2024 12:11:49

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.

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:

Kermit24 hat geschrieben:

02.08.2024 12:31:18

... drkonqi empfiehlt systemd-coredump"

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

Wir waren im Urlaub und sind gerade den 2.Tag wieder da. Und schon zerreißt es mir die X11-Session wieder:
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.

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

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

und dann

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