StartX funktioniert nicht. (Nicht genug Platz?)

754
Kitty Hawk

Mein Debian funktionierte bis gestern einwandfrei. Ich hatte Reaver, Aircrack und Kismet installiert und eine Weile mit ihnen gespielt (könnten sie der Täter sein?). Aber jetzt verbindet sich der X-Server nicht mehr. Ich habe keinen Desktop-Manager installiert, also habe ich immer manuell startx(wm = awesome) ohne Probleme. Jetzt kann ich nicht Ich werde die Symptome hier aufschreiben. Ich hoffe, Sie werden das Problem diagnostizieren und Lösungen vorschlagen.

  1. Was startxsagt: Der XKEYBOARD keymap compiler ( xkbcomp) berichtet:

    Error: cannot close "/tmp/server-0.xkm" properly (not enough space?) ... output file "tmp/server-0.xkm" removed. Errors from xkbcomp are not fatal. AIGLX:suspending AIGLX clients for VT switch (EE) server terminated with error (1) ... 

    Die xorg.0.logAkte sagt im Grunde dasselbe. ( Keyboard initialization failed, could be missing or incorrect setup of xkeyboard-config)

    Merkwürdig ist, dass berichtet wird, dass möglicherweise nicht genügend Speicherplatz vorhanden ist. Das letzte Mal, als ich nachgesehen habe, war mehr als genug Platz (20 Gigs) vorhanden.

  2. Wenn ich Reaver, Kismet und Aircrack geläutert habe: Alles läuft gut, aber es sagt, dass es kein Update Mandb geben kann, weil es keinen Platz hat.

  3. ls on /: Wenn ich cd /;ls, ist das /tmpVerzeichnis das einzige Verzeichnis, das grün hervorgehoben ist (bg = grün, fg = schwarz). Ich finde es verdächtig.

  4. Wenn ich die .XsessionsDatei lösche und dann startx: Die Fehlermeldungen bezüglich der Tastatur sind weg, aber AIGLX-Clients werden immer noch angehalten (Server wird mit Fehler beendet)

  5. Was ich df -isage: Alles ist gut, nur 10% Inoden werden verwendet.

  6. Was df -hsagt: Was? Die Root-Partition ist vollständig gefüllt. (24 von 24 Gigs) Ich habe apt-get cleanes getan und sagt immer noch, dass es komplett gefüllt ist.

Okay Jungs, wir alle wissen, was das Problem ist: root ist komplett gefüllt. Natürlich habe ich es nicht getan. Es würde viel zu lange dauern, 20 Gigs von Daten herunterzuladen, die ich nicht bemerken würde (ich habe eine Downloadgeschwindigkeit von 20 kbps). Es würde auch lange genug dauern, um so viele Daten als Protokoll oder etwas zu schreiben. (Root ist sowieso schreibgeschützt.)

Jemand in den Foren behauptete, das Problem behoben zu haben pacman -Scc. Ich habe es versucht apt-get cleanund es hat nicht funktioniert.

So wende ich mich jetzt an euch, um Hilfe zu bekommen. Bitte schlagen Sie vor, was ich als nächstes versuchen sollte.

4
Ich wollte es in unix.stackoverflow posten, aber ich habe es hier falsch gemacht. Ich werde es nach 40 Minuten verschieben. Kitty Hawk vor 7 Jahren 0
Haben Sie versucht herauszufinden, welches Verzeichnis für das Füllen Ihrer Partition verantwortlich ist? Versuchen Sie als Sudo * du -h --max-depth = 1 -x *. MariusMatutiae vor 7 Jahren 0
Ihre Frage ist sowohl für [su] als auch für [unix.se] ein Thema, also können Sie beide posten. Ich habe gerade ein Edit vorgeschlagen, das Markdown-Formatierungen hinzufügt, um das Lesen der Frage zu erleichtern. Anthony Geoghegan vor 7 Jahren 0
@MariusMatutiae du hat es geschafft und ich habe die riesigen Protokolle erfolgreich beseitigt. Danke für den Vorschlag. Kitty Hawk vor 7 Jahren 0
@AnthonyGeoghegan Danke für die Formatierung. Ich habe damals meinen mobilen Browser benutzt, also konnte ich es nicht. Kitty Hawk vor 7 Jahren 0
Kein Problem. Sie haben viele nützliche Informationen zur Verfügung gestellt, und ich dachte, ich würde versuchen, den Leuten das Parsen zu erleichtern. Jetzt, wo ich darüber nachdenke, sollte Ihre Frage eine Bestätigung erhalten, wenn Sie viel Forschungsaufwand zeigen und das Problem mit vielen relevanten Details klar darlegen. Willkommen bei [se]. Anthony Geoghegan vor 7 Jahren 0

1 Antwort auf die Frage

1
Anthony Geoghegan

Wenn dfmeldet, dass eine Partition voll ist, ist der duBefehl der nächste Schritt zur Problemdiagnose. Ich würde cddas Dateisystem root ausführen und ausführen

sudo du -smx * .[^.]* | sort -n 
  • Die -s( --summarize) Option druckt die Gesamtgröße für jede Datei / Verzeichnis.
  • Die -mOption gibt den von jeder Datei / Verzeichnis belegten Speicherplatz in Megabytes aus.
  • Die Option -x( --one-file-system) zwingt dudazu, im ursprünglichen Dateisystem zu bleiben. Dies läßt irrelevante (zu diesem Zweck!) Infos wie alle Dateien in /run, /sys, /devund / oder /proc(danke, MariusMatutiae).
  • Das [^.].*beinhaltet versteckte Dateien, während das übergeordnete Verzeichnis unter Ausschluß ..).
  • Durch das numerische Sortieren der Liste werden schließlich die Verzeichnisse angezeigt, die am Ende der Liste am meisten Platz beanspruchen.

Ich wechsle dann in das Verzeichnis, das am meisten Platz beansprucht, und wiederhole den Vorgang für seine Unterverzeichnisse. Schließlich sollten Sie ein Verzeichnis finden, das mehr Speicherplatz beansprucht, als es sein sollte.

Übrigens /tmp/soll weltweit schreibbar sein (was zum grünen Hintergrund führt). Der Inhalt sollte automatisch vom Betriebssystem regelmäßig gelöscht werden. Möglicherweise müssen Sie jedoch alte Dateien, die nicht automatisch bereinigt wurden, manuell löschen.

Persönlich /homemounte ich immer auf ein separates Dateisystem und wann immer mir dies passierte, fand ich den Täter als Protokolldateien /var/log.

Möglicherweise möchten Sie die Option * -x * hinzufügen, wodurch * du * im ursprünglichen Dateisystem verbleibt. Dies lässt irrelevante (zu diesem Zweck!) Informationen wie alle Dateien in * / run, / sys, / boot, / dev, /lost+found ... aus. MariusMatutiae vor 7 Jahren 0
Danke @MariusMatutiae Ich habe meine Antwort so bearbeitet, dass sie diese Option enthält. Anthony Geoghegan vor 7 Jahren 0
Ahh danke. Die Schuldigen waren diese Protokolldateien in / var, wie Sie es vorhergesagt hatten. Ich frage mich, was diese Inflation über Nacht verursacht hat. Kitty Hawk vor 7 Jahren 1
Es lohnt sich, die Protokolle zu überprüfen, um zu sehen, was so viel protokolliert wird, und versuchen Sie zu verhindern, dass es erneut auftritt. Ich weiß, dass einige Administratoren `/ var / log` auf einer separaten Partition einhängen, um genau dieses Problem zu vermeiden. Es ist wahrscheinlich die beste Praxis, und ich sollte es selbst tun. Anthony Geoghegan vor 7 Jahren 1
Bei einigen, aber seltenen Inodes können Ihnen sogar Inodes mit ähnlichen Symptomen ausgehen. Mit 'df -i' können Sie überprüfen, ob Sie vermuten, dass dies der Fall ist. Fred Clausen vor 7 Jahren 0