Beiträge von luigi

    Einfacher wäre folgende Abfrage gewesen:

    Code
    systemctl status avahi.service

    oder da er in deiner Liste auftritt mal testweise abschalten (als root)

    Code
    systemctl stop avahi.service


    Danach systemctl stop cups.service, nochmals den Ordner /var/cache/cups, dessen Inhalt du hier mal zeigen könntest, umbenennen und systemctl start cups.service, wie du bereits früher gemacht hast.

    Danach können wir sehen, ob die falschen Druckereinträge auch ohne laufenden avahi daemon wieder auftauchen.

    Habe ich gemacht, allerdings ist die Meldung unverändert immer noch da.

    Wenn du tatsächlich die von Sauerland vorgeschlagenen Umbenennungen durchgeführt hast und nach dem Neustart trotzdem wieder die gleichen Fehlermeldungen erscheinen, so könnte das darauf hindeuten, dass die config-files nicht neu gelesen wurden, sondern sich der kernel stattdessen aus dem cache bedient und dabei auf alte (fehlerhafte) Dateien zugegriffen hat.


    Die Änderung der auskommentierten Zeile # include ... --> include if exist ... hätte m.E. zu keiner oder zu einer anderen Fehlermeldung führen müssen.


    Vielleicht kannst du mal nachsehen, was das folgende ergibt:

    Code
    ls -l /var/cache/apparmor/

    Bei mir werden dann einige Verzeichnisse angezeigt. Wenn man dann als root das zuletzt erstellte (neueste) anschaut, so kann man das mit dem Inhalt von /etc/apparmor.d/ abgleichen.


    In /var/cache/apparmor/*/ liegen Dateien aus /etc/apparmor.d/ zum schnelleren laden im Binärformat.


    Vermutlich könnte das Löschen einiger cache-Dateien das Problem lösen, aber ich empfehle erst auf die Meinung von Sauerland zu warten.






    Ich würde zumindest die Größe des tmpfs im smh auf einen maximalen Wert begrenzen. Ich habe mal gehört der sei per default bei halber Ramgröße, was ich zu viel finde. Wo stellt man den im Tumbleweed ein?

    Natürlich kann man das einstellen, auch wenn ich den Sinn des Vorhabens nicht verstehe! Temporär z.B. als root:

    Code
    mount -o remount,size=500M /dev/shm

    Falls das ganze einen reboot überleben soll, muss man eine entsprechende Zeile in die /etc/fstab einfügen.


    Aber nochmals, mit einer kleineren Größe von /dev/shm beginnt das System vermutlich früher zu swappen. Du brauchst dann also eine größere Swap-Partition. Letztendlich wird doch mit diesen Maßnahmen das an die Wand fahren nur etwas hinausgezögert.


    Also entweder keine fehlerhaften Anwendungen starten oder sie nicht zu lange laufen lassen, sondern diese gelegentlich zum Müllbeseitigen beenden bevor sie das System dicht machen.

    Kurze followup Frage: wo kann ich dem Tumbleweed sagen, dass er kein tmpfs im shm anlegen soll, sondern für /tmp & co direkt das fs auf der SSD nutzen soll?

    So wie ich das gesamte Memory-Management unter Linux verstehe, wäre das keine gute Idee. Außerdem ist RAM immer schneller als SSD. Auch würde ich alle von dir zuvor geänderten Einstellungen wie z.B. swappiness wieder auf die default-Werte stellen. Damit dokterst du doch letztendlich nur an den Symptomen herum.


    Die Ursache des Problems bei dir sind doch die fehlerhaft programmierten Programme chrome und signal-desktop. Dort sollte man mal ansetzten ...