staging.inyokaproject.org

res55 schrieb:

Danke für die umfangreiche Analyse. Sowas ist nicht selbstverständlich!

Umfangreich war das gar nicht. Es fällt halt auf, wenn sich Einträge wiederholen. Aber: Gern geschehen.

Da weiss ich nicht, was zu tun wäre.

Da gibt es auch keine Pauschallösung oder einen konkreten Ansatz, da da sehr viele Komponenten zusammenspielen. Mir fehlte da jetzt der Crash der Plasmashell, um Hinweise zu finden. Eventuell kommst du mit coredumpctl weiter, da sollte es eine Liste der verfügbaren letzten Abstürze geben, die sich einzeln aufrufen lassen.

ich kenne mich da schon gar nicht aus. In welchem Forum würde ich dazu um Hilfe bitten?

Hier 😉 Beziehungsweise auf launchpad nach bekannten Bugs suchen. Vielleicht äußert sich da noch jemand anderes zu.

Mit der Zeit habe ich vieles ausprobiert und dann nicht weiter verfolgt. So sind die unnützen Dienste entstanden. Wie werde ich die wieder los? -

Deinstallation der Pakete, Deaktivieren der Units/Sockets,… Das kommt immer auf den konkreten Fall an.

337 loaded units listed.

Wow. Ich habe auch über 200 auf meinem „Wollte ich schon immer mal neu aufsetzen“-System. 300 ist mal ne Ansage 😀

Um jetzt aber weiterzukommen, schau mal nach den coredumps, idealerweise nach plasmashell oder kwin-Crashes.

jetzt ist es gerade wieder passiert: ca 10h17

Hier das Logfile von Heute: https://drive.google.com/file/d/1Qi1jnKXJBa5N1vVDi2fLlyI9hrvNdrvW/view?usp=share_link

Plötzlich war kein Programm mehr zu bedienen, der Fensterrahmen war weg. Ich hatte versucht, die Programme mit speichern zu beenden, jedoch weiss ich nicht, ob das noch geklappt hat. Jedoch konnte ich diesmal normal ein Reboot veranlassen.

Kann man aus dem Logfile etwas erkennen?

Gruss Res

Ich kann das Logfile nicht mal öffnen — da kommt nur eine weiße (leere) Seite. Vermutlich nutzt google drive irgendwelche „bösen“ JavaScript-Dinge, die hier geblockt werden.

vielleicht klappt es hiermit: https://www.droppy.ch/IGeb7c14/5769085aa1479604033af99afbabdda5

Fast. Da sehe ich zumindest ne Seite und ne AGB zum annehmen. Wieso denn immer solche Datenfänger mit Cookies auslesen und sowas? Häng doch die Datei einfach hier an oder nutze Text-Paste-Services. Idealerweise funktioniert das dann mit curl LINK lesbar.

Die Errorlog ist mit 3 MB zu gross für pastebins. Ich weiss nicht, wie viele Minuten vor dem Absturz zurück das Log von Bedeutung ist. Gezippt hat es jedoch als Anhang hier geklappt.

Ja, das funktioniert 👍

Während ich dein Log lese, lies du journalctl 😉 Das log reicht über zwei Tage. Ich nutze meist journalctl -b, was seit dem letzten Neustart gilt.

Also, um den Zeitraum rum finden sich wieder viele AppArmor-Fehler → Integration der Snaps. Da bleibt dir nur dich an die Bugreports anhängen, die es da seit Jahren gibt. Abgesehen von möglicher fehlender Funktionalität sollten die aber keine Probleme machen.

• Ein Crash im Sinne von coredump oder so ist da aber auch nicht zu erkennen

• Ein cronjob fordert stets Rootrechte an und versucht irgendwas mit mails zu machen (fehler: „No MTA installed, discarding output“)

• nach dem Aufruf von xdg-desktop-portal-kde taucht der Fehler „Qt:·Session·management·error:·networkIdsList·argument·is·NULL“ auf. Dieser ist vermutlich ein Folgefehler von den AppArmor-Geschichten, die DBus verhindern. Du kannst aber auch mal prüfen, ob $XDG_RUNTIME_DIR gesetzt ist. Vermutlich beisst sich da die Katze in den Schwanz, weil Snap nur ins $HOME darf, dieser Ordner aber für gewöhnlich im tmpfs liegt (/var/run, /run, /tmp, …). Auch kein schwerwiegendes Problem — Kann aber natürlich dazu führen das Funktionalitäten nicht gewährleistet sind.

• LibreOffice und KF5 kannst du dir als Positivbeispiel angucken: Das ist korrekt eingerichtet und erlaubt AppArmor-Vorgänge wie vorgesehen (vermutlich kein Snap?)

• Ich sehe, dass da viele Programme beendet werden:

  Apr 05 10:17:56 res-ThinkPad-E590 systemd[3190]: app-org.telegram.desktop._927ed94ab250229cbaa4f5d2c40e35ed-f744a9b1848b48639866378dbef0638e.scope: Consumed 58.381s CPU time.
  Apr 05 10:18:37 res-ThinkPad-E590 systemd[3190]: app-discord-580081e79a52497f8cbaf7e73de6c3ed.scope: Consumed 1h 9min 16.556s CPU time.
  Apr 05 10:19:41 res-ThinkPad-E590 systemd[3190]: app-libreoffice\x2dcalc-849aae6cc3094dc19bd1c4e4683c79b7.scope: Consumed 16min 38.729s CPU time.
  Apr 05 10:19:51 res-ThinkPad-E590 systemd[3190]: app-thunderbird-9888967631f948299435585e0fa826dd.scope: Consumed 33min 977ms CPU time.
  Apr 05 10:19:57 res-ThinkPad-E590 systemd[3190]: snap.keepassxc.keepassxc.2b020394-f4ad-42b0-966b-6a961a6411f3.scope: Consumed 43.161s CPU time.
  Apr 05 10:20:02 res-ThinkPad-E590 systemd[3190]: app-org.kde.dolphin-fc1ad572504a4b8fb0d45603a926344e.scope: Consumed 19min 13.876s CPU time.
  Apr 05 10:21:09 res-ThinkPad-E590 systemd[3190]: app-org.kde.konsole-128a90a46ec74746ba53e24918b0bd58.scope: Consumed 32.529s CPU time.
  Apr 05 10:21:09 res-ThinkPad-E590 systemd[3190]: plasma-ksystemstats.service: Consumed 1h 9min 24.113s CPU time.
  Apr 05 10:21:09 res-ThinkPad-E590 systemd[3190]: app-org.kde.plasma\x2dsystemmonitor-10e15d59e6004274b5d67c5aad7c360c.scope: Consumed 1h 40min 1.645s CPU time.
  Apr 05 10:21:09 res-ThinkPad-E590 systemd[3190]: app-org.kde.dolphin-20e8f7dbac8f4a63ac9af67b29496b04.scope: Consumed 8min 57.148s CPU time.
  Apr 05 10:21:09 res-ThinkPad-E590 systemd[3190]: xdg-desktop-portal-gnome.service: Consumed 15.922s CPU time.
  Apr 05 10:21:09 res-ThinkPad-E590 systemd[3190]: xdg-desktop-portal-gtk.service: Consumed 4.264s CPU time.

  ab 10:20 aber vermutlich durch den Logout, den du versuchst.

• Nach dem DBus-Blockieren um 10:16:39 kommt wieder der Session-Management-Fehler und im Anschluss kann kIO file:/// nicht mehr zu einem Pfad umwandeln. Eventuell Probleme mit der Partition deines $HOME? systemctl status home-res.mount

Also was ich sehe ist, das nach dem Klick auf Hochladen im Firefox einiges passiert. Allerdings kein Crash. Das könnte auch einfach bedeuten, dass das System glaubt zu hängen und Prozesse neu starten zu müssen. Eventuell verschwinden daher die Leisten und das System hängt.

Eventuell kannst du noch mal dein CRON-Script prüfen, ob das ordentlich beendet wird und ob überall ausreichend freie Inodes sind (df -i) und ob deine Container irgendwelche Fehler werfen (Docker).

Beim Herunterfahren selbst gibt es auch noch ein paar Dinge die auffallen, allerdings sollten die nicht den laufenden Betrieb stören.

Ich würde jetzt beim Festplattenstatus ansetzen, wobei ich kaum glaube, das eine Samsung 870 mal aufgibt, daher eher die Seagate, die sind lange dafür bekannt gewesen und auch den USB-Speicher, falls unterstützt. Beim Start verschluckt sich das mounten auch. Muss aber nix heißen, vielleicht sind die Platten an der Stelle noch nicht so weit. Interessant aber, das Snap so früh geladen wird (Suche bspw. nach chromium_chromedriver)

Unterm Strich würde ich aber einfach vermuten, dass da zu viel durcheinander läuft. Schwer das im Journal zu prüfen, da müsste schon viel Debug aktiviert werden → und das will wirklich keiner lesen 😉