SSD füllt sich selbständig

[Buerste]

Hallo an alle
Ich habe Debian testing und seit heute habe ich das Problem das sich die Festplatte "von selbst" vollschreibt. Ich kann schon fast dabei zuschauen so schnell geht das von statten.
Starte ich den Rechner neu ist alles wieder für ca 10 min gut. Dann geht das ganze wieder von vorne los. Zuerst hatte ich die .xsession-errors im verdacht, aber die ist es nicht.
Leider kann ich auch so nicht feststellen (mangels Fachwissen) woran es liegt oder liegen könnte. Hat evtl einer von euch eine Idee?

Danke schonmal im voraus für eure Hilfe

[Buerste]

kleiner Nachtrag...
hab jetzt zwei Dateien gefunden die infrage kommen
zum einen ist es die Datei xsession-rolf
und die zweite ist fileVwt5uy
beide befinden sich im Ordner /tmp und wachsen stetig an....

[DeletedUserReAsG]

/tmp ist normalerweise ein tmpfs, liegt also im RAM. Ob’s bei dir anders ist, zeigt dir die Ausgabe von mount. Ansonsten ist du, oder, etwas bequemer, ncdu gut, um Platzfresser zu finden. Mit lsof kannst du dann schauen, welcher Prozess die betreffende Datei geöffnet hat.

[rendegast]

Ansonsten ist du, oder, etwas bequemer, ncdu gut, um Platzfresser zu finden.

Im hier wohl vorliegenden Fall einer anwachsenden (deleted)-Datei ist diese und ihre anwachsende Größe wohl nur per lsof anzeigbar.
ZBsp. die Auslagerung einer per '-snapshot' gestarteten qemu-VM.
(Das Anwachsen wäre von den Aktivitäten der VM abhängig.)

[DeletedUserReAsG]

Ich halt’s da eher mit Ockham und würde erstmal die einfachen, naheliegenden Möglichkeiten in Betracht ziehen, sofern keine anderslautenden Informationen vorliegen.

[KBDCALLS]

Finden sich Hinweise im Odner /var/log speziell in der Messages Datei.

[MSfree]

Finden sich Hinweise im Odner /var/log speziell in der Messages Datei.

/var/log/mesasages? Im Zeitalter von systemd?

Lieber

Code: Alles auswählen

journalctl -f

in einem Terminal laufen lassen und schauen, was da so eintrudelt.

[Lord_Carlos]

Wie gross werden denn die beiden Daten? Also Sprechen wir hier von kb, mb oder gb?

[Buerste]

Hallo zusammen,
erstmal vielen dank für eure Hilfe.

Wie gross werden denn die beiden Daten? Also Sprechen wir hier von kb, mb oder gb?

Es sind tatsächlich GB, und es geht relativ schnell.
Die Part ist 80GB gross und standartmässig sind vielleicht 15 GB belegt. Es dauert dann ungefähr ½ std und die Part ist voll!
Ein Neustart führt dazu das die Part wieder auf das "Standart-Volumen" zurückgesetzt wird.

Die Ausgabe von ' du - sh * bringt folgendes zu Tage

Code: Alles auswählen

rolf@Rolf:~$  du -sh *
5,1M	Bilder
1,1M	Dokumente
437M	Downloads
46M	hplip-3.16.9
22M	hplip-3.16.9.run
0	Musik
0	Öffentlich
124K	Schreibtisch
0	SDwjczKwUN
36K	troubleshoot.txt
0	Videos
0	Vorlagen
rolf@Rolf:~$ 

Wenn ich das als root laufen lasse sprengt das ganze doch ein wenig den Rahmen.... von daher habe ich mal nur die letzten Zeilen hier eingestellt

Code: Alles auswählen

1088468	/home/rolf/.icedove/eqmxusf6.default/ImapMail/secureimap.t-online.de
1092468	/home/rolf/.icedove/eqmxusf6.default/ImapMail
1102440	/home/rolf/.icedove/eqmxusf6.default
1102444	/home/rolf/.icedove
1167404	/usr/lib/x86_64-linux-gnu
2048716	/var/cache/apt/archives
2100876	/var/cache/apt
2125660	/var/cache
2432092	/var
2436680	/usr/share
2549760	/usr/lib
2639388	/tmp
3227436	/home
3227436	/home/rolf
5380552	/usr
14191896	/
root@Rolf:/home/rolf# 

Während ich das schreibe sind wieder ca 10GB an Daten auf die SSD geschrieben worden .

Die Ausgabe von journalctl -f schaut wie folgt aus...

Code: Alles auswählen

-- Logs begin at Mi 2016-10-26 15:14:50 CEST. --
Okt 26 15:23:46 Rolf dbus-daemon[1021]: Successfully activated service 'org.gnome.Terminal'
Okt 26 15:23:46 Rolf systemd[996]: Started GNOME Terminal Server.
Okt 26 15:24:51 Rolf anacron[606]: Job `cron.weekly' started
Okt 26 15:24:51 Rolf anacron[7140]: Updated timestamp for job `cron.weekly' to 2016-10-26
Okt 26 15:24:53 Rolf anacron[606]: Job `cron.weekly' terminated
Okt 26 15:24:53 Rolf anacron[606]: Normal exit (2 jobs run)
Okt 26 15:26:48 Rolf su[7173]: Successful su for root by rolf
Okt 26 15:26:48 Rolf su[7173]: + /dev/pts/0 rolf:root
Okt 26 15:26:48 Rolf su[7173]: pam_unix(su:session): session opened for user root by (uid=1000)
Okt 26 15:26:48 Rolf su[7173]: pam_systemd(su:session): Cannot create session: Already occupied by a session

ich hoffe euch damit weiter Info geben zu können
Da fällt mir noch ein, ich nutze btrfs als Filesystem, ich weiss nicht ob das relevant ist.

[KBDCALLS]

Finden sich Hinweise im Odner /var/log speziell in der Messages Datei.

/var/log/mesasages? Im Zeitalter von systemd?

Lieber

Code: Alles auswählen

journalctl -f 

in einem Terminal laufen lassen und schauen, was da so eintrudelt.

Das eine muß ja das andere nicht ausschließen. Und wie reicht das Log zurück? Und soweit ich weiß logt systemd nicht alles. Das Program muß auch mitspielen damit das funktioniert. Ähnliche Geschichte mit Cron und Systemd

[TomL]

Und soweit ich weiß logt systemd nicht alles.

Nein umgekehrt..... rsyslog ist quasi tod und hängt nur noch an der Herz-Lungenmaschine. Das heisst, alle Meldungen, die rsyslog in den Logs speichert ist heute vorgekauter Brei, weil rsyslog seine Meldungen komplett von systemd-journald bekommt.... damit ist das eine völlig unnötige redundante Speicherung von Log-Einträgen. Der einzig sinvolle Weg ist meiner Meinung nach:

Code: Alles auswählen

apt-get purge --remove rsyslog

[MSfree]

Und wie reicht das Log zurück?

Die gleiche Frage stellt sich bei /var/log/messages. Aber in diesem Fall ist scheinbar die Platte in einer halben Stunde nach dem Boot schon voll. Selbst, wenn das Log bloß bis zum Reboot zurückreicht, sollte alles relevante dort zu finden sein.

Und soweit ich weiß logt systemd nicht alles.

In seiner Defaulteinstellung logt systemd alles, während in /var/log/messages nur ein unvollständiges Log ankommt.

Man muß schon selbst Hand anlegen und alles via rsyslogd pipen und rsyslod.conf manuell anpassen, damit /var/log/messages alles enthält. Und überhaupt, bei mir heißt die globale alles-drin Logdatei /var/log/syslog und auf die binären Journalfiles gibt es bei mir gar nicht.

[MSfree]

Der einzig sinvolle Weg ist meiner Meinung nach:

Code: Alles auswählen

apt-get purge --remove rsyslog

Veto!

Wie bekommt man seine Logmeldungen sonst über das Netzwerk an einen Loghost geschickt?
Meiner Meinung nach gehört dieser idiotische Journald abgewürgt, aber das ist leider unmöglich.

[TomL]

Wie bekommt man seine Logmeldungen sonst über das Netzwerk an einen Loghost geschickt?

äääh..... ich würde ganz einfach /var/log/journal/* über einen cronjob irgendwohin oder auf irgendeinen Server kopieren lassen... sofern das heute überhaupt noch notwendig ist. Bei meinem PI mach ich das zyklisch, da /var/log nach tmpfs gemountet ist. Aber ansonsten.... denn genau der Punkt, der Loghost bei rsyslog notwendig gemacht hat, und zwar die mangelhafte Manipulationssicherheit, gibts bei journald nicht mehr. Die Logs sind imho revisionssicher. Und wenn ich mir die Logs anderer Maschinen ansehen möchte, mach ich das einfach via ssh..... die Logs nur dafür alle auf nem Server vorzuhalten wäre mir viel zu aufwendig.

https://plus.google.com/115547683951727 ... 1E6AxVKtyc

Allerdings lass ich mich gerne belehren, wenn ich da was falsch verstanden habe.

[MSfree]

äääh..... ich würde ganz einfach /var/log/journal/* über einen cronjob irgendwohin oder auf irgendeinen Server kopieren lassen...

Das erzähl mal den zahlreichen WLAN-Accesspoints da draussen, die ihre Logs bis heute brav via syslog-Protokoll auf beliebige Loghosts schicken. Ausserdem habe ich so die Logs via rsyslogd an einer zentralen Stelle und in Echtzeit und nicht nur einmal pro Tag.

Wie gesagt, das jounaling im systemd ist eine Katastrophe, angefangen bei der idiotischen Idee, das alles in Binärdateien zu speichern bis zur Unfähigkeit, über das Netz zu loggen. Der Sicherheitsaspekt ist übrigens via SSL ganz schnell kein Prrolem mehr. Und wer dann immer noch alle Logs in einer Datenbank haben will (also binär) kann rsyslogd das nach mysql oder sonst eine belibige Datenbank loggen lassen.

[TomL]

ja, ok... das sind anscheinend besondere Umstände... an AP habe ich nicht gedacht und ich habe mich mit der Fragestellung noch nicht beschäftigt. Ich weiss nicht, welche Lösungen da sinnvoll sind. Aber als Katastrophe sehe ich nur das verbissene Festhalten an alten Gewohnheiten. Und was das Binaerformat angeht, das finde ich beispielsweise richtig gut. Meiner Meinung nach hat da niemand was mit nem Editor oder Txt-Listern oder direktem grep'n drin verloren. Journalctl lässt für meine kleinen Bedürfnisse jedenfalls keine Wünsche unerfüllt.

Vielleicht ist das das Problem "meine kleinen Bedürfnisse".... möglich, dass es mehr gibt.... möglich ist aber auch, dass es für das mehr auch schon Lösungen gibt.

[DeletedUserReAsG]

Journald ist sehr wohl netzwerkfähig, du kannst einen zentralen Logserver aufsetzen. Außerdem finde z.B. ich die zusätzlichen Informationen, die journald gegenüber den herkömmlichen Lösungen bietet, vorteilhaft. So what?

Aber letztlich ist das hier OT; ob die Logausgaben in diesem Fall nun von journald oder (r)syslogd oder dmesg stammen, ist unerheblich – schöner wären unabgeschnittene Ausgaben von du, die Ausgabe von der obersten Ebene sollte dazu nicht rekursiv in die Verzeichnisse gehen. Auch wäre die Option h wünschenswert (zumindest ich komme damit besser klar, als mit Bytes im Milliardenmaßstab).

[TRex]

Bitte nicht mit systemd vom Thema ablenken, danke.

[Buerste]

Moin @all
Erst einmal vielen Dank an alle die sich hier eingebracht haben.
Leider habe ich das Problem nicht lösen können und auf Grund dessen mich dazu entschieden ein altes Image zurück zu spielen.

Grüße
Bürste

[reox]

Wenn ich das als root laufen lasse sprengt das ganze doch ein wenig den Rahmen.... von daher habe ich mal nur die letzten Zeilen hier eingestellt

mach doch mal ein

Code: Alles auswählen

du -sh /* | sort -h | tail

dann siehst du gleich was groß wird. In den Ordner gehst du dann rein und schaust dort wieder den größten an usw...
alternativ könntest du auch mit einem

Code: Alles auswählen

find / -type f -exec du -h {} \; | sort -h | tail

die größten dateien anzeigen lassen... dauert halt wesentlich länger.