Man wundert sich ja manchmal schon, was die Platte so alles vollmüllt… Hat man genug Platz und achtet nicht sonderlich auf ein paar MB, GB usw. ist auf einmal ein Device voll. Und das war nun /var. Extra als eigene Partition angelegt, um das restliche System nicht zu stören. Hat es auch nicht, nun ist aber der verbliebene Rest auf wenige zig MB geschrumpft. Und noch während ich auf der Suche war waren auch die letzten MBs weg. Gesamte Partition zu 100% belegt. Der komplette freie Platz verschwunden.
Nur wohin?
Kurzerhand war /var/log/syslog als Übeltäter identifiziert. Mehrere 100MB groß und mit Unmengen an Loggingeinträgen, die auch in dmesg zu finden sind. Jede Sekunde mehrere Einträge, die sich immer wiederholten….
kernel: Valid eCryptfs headers not found in file header region or xattr region
kernel: Either the lower file is not in a valid eCryptfs format, or the key could not be retrieved. Plaintext passthrough mode is not enabled; returning -EIO
Also mal Google befragt, was das so sein könnte. Ergebnis: Wohl ein lange gepflegter Bug. So richtig voran kommen die wohl nicht, der existiert auch schon seit einigen Release-Versionen (und damit seit JAHREN! ;-( ). Ideen zur Behebung der Meldungen gibt es viele, ebenso Vermutungen. Bei dem Einen ist es das .Skype Verzeichnis, beim Nächsten was anderes. So richtig einheitlich ist es alles nicht.
Lösungsmöglichkeiten?
Wohl wenige. Nun ja, eigentlich sollte das lieber mal im Kernel gefixt werden. Es scheint ja ein generelles Ubuntu-Problem seit einigen Jahren zu sein. Da man aber nun nicht unbedingt seinen eigenen Kernel bauen möchte und lieber im normalen Release-Tree von Ubuntu bleibt also eher die Holzhammer-Methode. Frei nach dem Motto “bist du nicht willig, so nutze ich Gewalt…”. Man sollte gut drüber nachdenken, ob man das nun macht oder vll. lieber nicht. Mir ist das aufgeräumte Log, welches sich nicht binnen Minuten um zig MB erweitert, lieber. Also schnell mal alle Dateien, die “nur so da sind” und keinen Speicher verbrauchen suchen:
Shell #> find /home/$USER/ -xdev -size 0c -exec ls '{}' \;
Das war bei mir eine recht beträchtliche Anzahl. Ob nun diese Dateien alle verantwortlich sind oder nur einzelne, egal. Weg mit denen. Zur Not hat man ja ein Backup 
Shell #> find /home/$USER/ -xdev -size 0c -exec rm '{}' \;
(Achtung: Erst denken, dann tippen. KEINE Gewähr. Jeder ist für sein Handeln selber verantwortlich!)
Danach war’s ruhig im Log. Dmesg und syslog zeigten keine Meldungen mehr. Auch nach mehrfachen Reboots war nichts mehr von den Auswirkungen des Bugs zu sehen.
Man kann natürlich darüber streiten, ob es der richtige Weg ist, einfach reinzuschlagen und so für Ruhe im System zu sorgen. Aber manchmal hilft (schon aus Zeitgründen) nur der harte Weg……
Trotzdem würde ich mich natürlich freuen, demnächst mal eine Lösung dafür zu sehen. Haaaaaalloooo, Ubuntu?!
Man wundert sich ja manchmal schon, was die Platte so alles vollmüllt... Hat man genug Platz und achtet nicht sonderlich auf ein paar MB, GB usw. ist auf einmal ein Device voll. Und das war nun /var. Extra als eigene Partition angelegt, um das restliche System nicht zu stören. Hat es auch nicht, nun ist aber der verbliebene Rest auf wenige zig MB geschrumpft. Und noch während ich auf der Suche war waren auch die letzten MBs weg. Gesamte Partition zu 100% belegt. Der komplette freie Platz verschwunden.
Nur wohin?
Kurzerhand war /var/log/syslog als Übeltäter identifiziert. Mehrere 100MB groß und mit Unmengen an Loggingeinträgen, die auch in dmesg zu finden sind. Jede Sekunde mehrere Einträge, die sich immer wiederholten....
kernel: Valid eCryptfs headers not found in file header region or xattr region
kernel: Either the lower file is not in a valid eCryptfs format, or the key could not be retrieved. Plaintext passthrough mode is not enabled; returning -EIO
Also mal Google befragt, was das so sein könnte. Ergebnis: Wohl ein lange gepflegter Bug. So richtig voran kommen die wohl nicht, der existiert auch schon seit einigen Release-Versionen (und damit seit JAHREN! ;-( ). Ideen zur Behebung der Meldungen gibt es viele, ebenso Vermutungen. Bei dem Einen ist es das .Skype Verzeichnis, beim Nächsten was anderes. So richtig einheitlich ist es alles nicht.
Lösungsmöglichkeiten?
Wohl wenige. Nun ja, eigentlich sollte das lieber mal im Kernel gefixt werden. Es scheint ja ein generelles Ubuntu-Problem seit einigen Jahren zu sein. Da man aber nun nicht unbedingt seinen eigenen Kernel bauen möchte und lieber im normalen Release-Tree von Ubuntu bleibt also eher die Holzhammer-Methode. Frei nach dem Motto "bist du nicht willig, so nutze ich Gewalt...". Man sollte gut drüber nachdenken, ob man das nun macht oder vll. lieber nicht. Mir ist das aufgeräumte Log, welches sich nicht binnen Minuten um zig MB erweitert, lieber. Also schnell mal alle Dateien, die "nur so da sind" und keinen Speicher verbrauchen suchen:
Shell #> find /home/$USER/ -xdev -size 0c -exec ls '{}' \;
Das war bei mir eine recht beträchtliche Anzahl. Ob nun diese Dateien alle verantwortlich sind oder nur einzelne, egal. Weg mit denen. Zur Not hat man ja ein Backup ;-)
Shell #> find /home/$USER/ -xdev -size 0c -exec rm '{}' \;
(Achtung: Erst denken, dann tippen. KEINE Gewähr. Jeder ist für sein Handeln selber verantwortlich!)
Danach war's ruhig im Log. Dmesg und syslog zeigten keine Meldungen mehr. Auch nach mehrfachen Reboots war nichts mehr von den Auswirkungen des Bugs zu sehen.
Man kann natürlich darüber streiten, ob es der richtige Weg ist, einfach reinzuschlagen und so für Ruhe im System zu sorgen. Aber manchmal hilft (schon aus Zeitgründen) nur der harte Weg......
Trotzdem würde ich mich natürlich freuen, demnächst mal eine Lösung dafür zu sehen. Haaaaaalloooo, Ubuntu?!