Fehler auf Dateisystem

[findus]

Hallo,

heute wunderte ich mich über ein Platzproblem auf unserem Mail-Server. Ein beherztes "df -h" ergab, dass das Verzeichnis /var mit 100% ausgelastet ist. Nach einem Neustart war das Problem behoben - jedoch hatte ich ein komisches gefühl und habe mit fsck das Dateisystem überprüft:

** /dev/ar0s1a (NO WRITE)
** Last Mounted on /
** Root file system
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
1011 files, 20120 used, 106719 free (1407 frags, 13164 blocks, 1.1% fragmentation)
** /dev/ar0s1e (NO WRITE)
** Last Mounted on /tmp
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
39 files, 86 used, 1012929 free (25 frags, 126613 blocks, 0.0% fragmentation)
** /dev/ar0s1f (NO WRITE)
** Last Mounted on /usr
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
SUMMARY INFORMATION BAD
SALVAGE? no

BLK(S) MISSING IN BIT MAPS
SALVAGE? no

138012 files, 3484595 used, 31704313 free (24641 frags, 3959959 blocks, 0.1% fragmentation)
** /dev/ar0s1d (NO WRITE)
** Last Mounted on /var
** Phase 1 - Check Blocks and Sizes
INCORRECT BLOCK COUNT I=151473 (24 should be 0) CORRECT? no

INCORRECT BLOCK COUNT I=188419 (240 should be 224) CORRECT? no

INCORRECT BLOCK COUNT I=188423 (988832 should be 988800) CORRECT? no

** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
UNREF FILE I=147643 OWNER=postfix MODE=100700
SIZE=6659 MTIME=Jul 18 19:27 2006
RECONNECT? no


CLEAR? no

UNREF FILE I=149262 OWNER=postfix MODE=100700
SIZE=8236 MTIME=Jul 18 18:37 2006
RECONNECT? no


CLEAR? no

UNREF FILE I=150791 OWNER=filter MODE=100744
SIZE=7059 MTIME=Jul 18 18:21 2006
RECONNECT? no


CLEAR? no

UNREF FILE I=150844 OWNER=filter MODE=100744
SIZE=6935 MTIME=Jul 18 18:21 2006
RECONNECT? no


CLEAR? no

UNREF FILE I=151322 OWNER=postfix MODE=100700
SIZE=7156 MTIME=Jul 18 18:37 2006
RECONNECT? no


CLEAR? no

UNREF FILE I=151724 OWNER=postfix MODE=100600
SIZE=264 MTIME=Jul 18 18:21 2006
RECONNECT? no


CLEAR? no

UNREF FILE I=151756 OWNER=postfix MODE=100700
SIZE=8940 MTIME=Jul 18 18:21 2006
RECONNECT? no


CLEAR? no

UNREF FILE I=154406 OWNER=postfix MODE=100700
SIZE=31282 MTIME=Jul 18 19:27 2006
RECONNECT? no


CLEAR? no

** Phase 5 - Check Cyl groups
FREE BLK COUNT(S) WRONG IN SUPERBLK
SALVAGE? no

SUMMARY INFORMATION BAD
SALVAGE? no

BLK(S) MISSING IN BIT MAPS
SALVAGE? no

16484 files, 288492 used, 724434 free (20706 frags, 87966 blocks, 2.0% fragmentation)

Nun habe ich gerade versucht das Dateisystem im Single-User Modus zu reparieren. Also einmal neugstartet und dort ebenfalls das Dateisystem überprüft (fsck -F) - hier findet FreeBSD jedoch keinen einzigen Fehler?! Habe ich etwas übersehen oder nicht bedacht? Mein nächster Schritt wäre dann das reparieren mit fsck -y gewesen.

LG

Björn

 

[Maledictus]

Hast du fsck gemacht während das Dateisystem rw gemountet war?

 

[findus]

Hi Maledictus,

die zitierte Ausgabe stammt von einem im laufenden Betrieb durchgeführten fsck. Also einem System das nicht im Single User Betrieb gebootet wurde. Ich habe nach einer möglichen Fehlerquelle gesucht, die mir erklären könnte warum keine Mails zugestellt werden konnten. Nach einer Analyse der Logfiles vom Postfix fand ich den Hinweis, dass das Dateisystem zu 100% ausgelastet ist. Ein df -h bestätigte das.

Nach einem Neustart war das Problem behoben. Die Kapazität von /var lag dann wieder bei normalen 9%. Zur Sicherheit habe ich dann ein fsck im laufenden Betrieb durchgeführt... Das Dateisystem war also rw gemountet.

LG

Björn

 

[Maledictus]

Bin nicht ganz sicher, aber habe neulich auf einer deutschen Mailingliste gelesen, dass bei ein fsck bei einem rw gemounteten Dateisystem immer Müll produziert.

 

[Styx]

Hmmm...aber fsck wird doch auch im laufenden Betrieb vom System selber in regelmäßigen Abständen gestartet. Wäre also unlogisch, dass das nur bei ro gemounteten Dateisystemen richtig funktioniert.

 

[Yamagi]

Man muss zwischen Background-fsck und richtigem fsck unterscheiden. Ein Bakcground-fsck (fsck -B) erzeugt einen Snapshot, checkt diesen und schreibt Änderungen auf das gemountete Dateisystem zurück. Dies funktioniert allerdings nur mit einigen wenigen, speziellen Fehlern. Nämlich nur mit denen, die bei einem Dateisystem mit aktivierten Softupdates auftreten können.
Ein normales fsck erzeugt keinen Snapshot, sondern läuft auf dem gemounteten Dateisystem. Da das Dateisystem um gemounteten Zustand ständig Veränderungen unterworfen ist, kann es vorkommen, dass fsck Fehler findet, die es nicht gibt.

Wenn ein Dateisystem Fehler enthält, die ein Background-fsck nicht ausbügeln kann, weißt dieses den Benutzer normalerweise darauf hin. Leider versickert diese die Meldung in den Logfiles und wird nicht beachtet... Bei übelsten Fehlern kann es sein, dass er beim nächsten Boot unterbricht und mit der Aufforderung ein echtes fsck durchlaufen zu lassen in den Single User geht. Das ist allerdings sehr selten und mir nur ein einzige Mal passiert, als mir der Rechner dank instabiler Stromversorgung innerhalb von 10 Minuten mehrmals gecrasht war.

Kleiner Tipp: Ich habe mir angewöhnt, immer wenn es ein neues Release gibt und ich zum INSTALLWORLD eh in den Single User muss, einmal fsck bei nicht gemounteten Dateisystemen durchlaufen zu lassen. Er findet trotz eingeschaltetem Background-fsck fast immer kleinere - aber meist harmlose - Fehler.

 

[Imp]

Hi,

ich habe mir gestern mit Findus zusammen das Problem angesehen.
Es gabe neben den Meldungen von fsck und dem zu 100% gefüllten /var Verzeichnisses noch ein weiteres Problem.

/var ist auf einer Partition gemountet. Bei dem befehl df -h wurde angezeigt, dass diese Partition mit 100% belegt ist. Ein du -m auf dem Verzeichnis /var ergab aber, dass es nur 500 MB beinhaltet, die Partition für /var aber 1,9 GB Kapazität hat.
Nach dem Neustart des System wurde bei df -h auch nur eine Nutzung von 500 MB ausgegeben und der Rest als frei angezeigt.

Ein erneuter Check nach ca. 1 Stunde Betriebszeit ergab folgendes:
df -h : /var ist mit 650 MB belegt
du -m auf dem /var Verzeichnis : 550 MB

Woran könnte das es liegen? Hängen die Meldungen des fsck evtl. mit diesem problem zusammen?

Gruß Imp

 

[Kamikaze]

Was macht der Rechner denn so. Vielleicht ist es gar kein Problem.

 

[Maledictus]

Mit Softupdates ist sowas jedenfalls problemlos möglich, ohne das irgendein Fehler o.ä. vorliegt.

 

[Imp]

Was ich bisher beobachten konnte ist, dass die Diskrepanz zwischen den beiden Ausgaben von df -h und du -m immer weiter zu wachsen scheint.

Das sich dort ein kleiner Unterschied besteht kann ich mir erklären, da df -h die i-nodes mit zählt während du dies nicht macht.
Die einzige Erklärung hierfür wäre in meinen Augen ein hängender Prozess, dessen Speicherplatz nicht richtig freigegeben werden kann.
Aber dies hätte ja eigentlich keine Auswirkungen auf den fsck.

Der Server übernimmt folgende Aufgaben:
Mails annehmen, diese auf Spamm überprüfen und dann an einen weiteren Server weiterleiten

Gruß
Imp

 

[findus]

Mit Softupdates ist sowas jedenfalls problemlos möglich, ohne das irgendein Fehler o.ä. vorliegt.

Hi Maledictus,

das Konzept der Softupdates habe ich verstanden. Allerdings darf es meines Wissens nach nicht dazu führen, dass eine Partition zu 100% ausgelastet ist.
Ich habe /var mit knapp 2 GB angelegt - im normalen Betrieb liegt die Auslastung bei knapp 9%. Am meisten Platz benötigen die Log-Files vom Postfix. Auf das Probelm aufmerksam geworden bin ich, als Postfix keine weiteren E-Mails mehr annehmen konnte. In den Log-Files konnte man lesen, dass keine weiteren E-Mails zugestellt werden können, da das Dateisystem voll ist.

Als ich das Problem nicht weiter nachvollziehen konnte, habe ich das System neugestartet. Im Anschluß lag die benötigte Kapazität wieder bei normalen 9%.

Um mögliche Fehlerquellen zu entdecken habe ich das Dateisystem mit fsck geprüft. Als Betriebssystem setze ich FreeBSD 5.4 ein. Ein RAID ist mit FreeBSD aufgebaut. Eine Idee habe ich nicht mehr - aber ich möchte es natürlich umgehen, dass es zu einer Nichtzustellung von E-Mails kommt. Vielleicht hat ja noch jemand einen Tipp?!

Gruß Björn

 

[MrFixit]

Was ich bisher beobachten konnte ist, dass die Diskrepanz zwischen den beiden Ausgaben von df -h und du -m immer weiter zu wachsen scheint.

FAQ! FAQ! FAQ!

Die einzige Erklärung hierfür wäre in meinen Augen ein hängender Prozess, dessen Speicherplatz nicht richtig freigegeben werden kann.

Genau, offene Inodes eben. Du willst fstat und lsof ausprobieren.

 

[findus]

Hej,

ich habe leider seit Juli keine Zeit mehr gehabt mich noch einmal näher mit dem Problem zu beschäftigen. Heute habe ich es dann noch einmal probiert. Zu ersteinmal habe ich mit fstat mir die Prozesse inkl. offener Dateien angeschaut. Die Relevanten sind die Syslogprozesse auf /var, die mit Postfix zusammenhängen:

USER     CMD          PID   FD MOUNT      INUM MODE         SZ|DV R/W
root     syslogd      288    9 /var     188440 -rw-r--r--     359  w
root     syslogd      288   10 /var     188426 -rw-------       0  w
root     syslogd      288   11 /var     188418 -rw-------   48036  w
root     syslogd      288   12 /var     188419 -rw-r-----  91715367  w
root     syslogd      288   13 /var     188422 -rw-r--r--       0  w
root     syslogd      288   14 /var     188421 -rw-------       0  w
root     syslogd      288   15 /var     188441 -rw-------   51581  w
root     syslogd      288   16 /var     188420 -rw-------     471  w
root     syslogd      288   17 /var     188427 -rw-r-----       0  w
root     syslogd      288   18 /var     188428 -rw-r-----       0  w

Der Prozess der die knapp 90 MB (91715367 Bytes) frisst, ist derjenige der das /var/log/maillog füttert. Das Problem ist, dass ich die im Ausgangspost besprochene Situation (Dateisystem voll, kein Platz mehr zu annahme neuer Mails) nicht mehr nachstellen kann um dann noch einmal alle offenen Prozesse mir anzeigen zu lassen. Das es nicht passiert, ist einem ziemlich dreckigen "Hack" zu verschulden. In einem regelmäßigen Intervall wird der Server per Skrit neugestartet, bis zu diesem Zeitpunkt läßt sich aber erkennen das der Platz auf dem Dateisystem schwindet.

Das es eine natürlich Diskrepanz zwischen den Aussagen von df -h u. du -h gibt ist mir bewusst. Das es zu Fehlern bei einem fsck im laufenden Betrieb kommen kann, habe ich ebenfalls verstanden. Ein Test im Single-User-Mode habe ich heute noch einmal gemacht und es kam bei einem nicht-gemountetem Dateisystem zu keinem Fehler:

** /dev/ar0s1d
** Last Mounted on /var
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
3992 files, 159271 used, 853744 free (5848 frags, 105987 blocks, 0.6% fragmentation)

Bei ein wenig Nachdenken ist mir heute auch noch eine Kleinigkeit eingefallen, bei der ich nicht weiß, ob sie dieses Verhalten provoziert: Vor einiger Zeit habe ich unwissend das Logfile von Postfix gelöscht ohne den Prozess mit kill -HUP zu beenden. Folge war, dass er weiter in diese offene Datei geschrieben hat, obwohl nicht mehr existent. Nach der Reperatur (neues Logfile anlegen, mit anderem Namen, Logrotate ändern, System neustarten) was dies behoben. Seit diesem Zeitpunkt + 2 Wochen kam es zum Vollaufen des Dateisystems.

Hat jemand vielleicht eine Idee, wie ich herausfinden könnte, was mir nun den Speicherplatz klaut? Das Logfile ist dies nicht mehr. Ich möchte keine Anleitung haben, aber vielleicht Hinweise die mir nen Ansatzpunkt geben für weitere Recherchen geben. Hat vielleicht noch jemand eine Idee?

Björn

Ps.: Seit 1/2 Jahr zähle ich im Zivildienst Vögel und habe seitdem kein FreeBSD mehr administriert - schon verrückt was man so an alltäglichen Dingen vergessen hat...

Das nur so nebenbei.

 

[findus]

Hi,

auch wenn es bisher keine Antwort oder Idee gibt, hänge ich hier noch einmal das Newsyslogd.conf an. Ich habe dieses mir noch einmal genau angeschaut und entdecke keinen Fehler - ich vermute das Problem aber im Zusammenhang mit der Erstellung des Maillogs. Nur bin ich mit meinem Latein am Ende. Fstat zeigt mir ja nur einen Prozess auf /var der knapp 90 MB groß ist - das ist das Maillog. Weitere in der Größenordnung gibt es nicht, bzw. ich kann nichts entdecken, dass vllt. Hidden abgelegt wird. Ach, das Konfigfile:

# logfilename          [owner:group]    mode count size when  flags [/pid_file] [sig_num]
/var/log/all.log                        600  7     *    @T00  J
/var/log/amd.log                        644  7     100  *     J
/var/log/auth.log                       600  7     100  *     J
/var/log/console.log                    600  5     100  *     J
/var/log/cron                           600  3     100  *     J
/var/log/daily.log                      640  7     *    @T00  JN
/var/log/debug.log                      600  7     100  *     J
/var/log/kerberos.log                   600  7     100  *     J
/var/log/lpd-errs                       644  7     100  *     J
/var/log/maillog                        640  7     *    @T00  J
/var/log/vsftpd.log                     640  7     *    @T00  J
/var/log/spamd.log                      640  7     *    @T00  J
/var/log/messages                       644  5     100  *     J
/var/log/monthly.log                    640  12    *    $M1D0 JN
/var/log/pflog                          600  3     100  *     JB    /var/run/pflogd.pid
/var/log/ppp.log        root:network    640  3     100  *     J
/var/log/security                       600  10    100  *     J
/var/log/sendmail.st                    640  10    *    168   B
/var/log/slip.log       root:network    640  3     100  *     J
/var/log/weekly.log                     640  5     1    $W6D0 JN
/var/log/wtmp                           644  3     *    @01T05 B
/var/log/xferlog                        600  7     100  *     J

Für Rat bin ich dankbar

Björn

 

[Imp]

Greetinx.....

ich habe mir den Mailserver auch noch einmal angesehen, nachdem das maillog durch die newsyslog.conf automatisch gepackt worden ist.
Die Größendiskrepanz zwischen df -h und du -m auf dem var verzeichnis entsprechen exakt der Größe des Maillog zum Zeitpunkt des Packens.
Es scheint also bei diesem Prozess zu offenen Inodes zu kommen.

Hat jemand eine konkrete Idee, wie man dies lösen kann bzw. andere Alternativen?

Grüße
Imp

 

[indigo]

Hallo zusammen,

habt ihr schon etwas mehr darueber rausgefunden?
Ich habe das selbe Problem ebenfalls. Bei mir tritt es zyklisch auf vier Systemen auf.
Alle vier benutzen FBSD 4.11 Release (letzer Patchlevel) und Postfix. Ausserdem laeuft dort noch Antivir von Avira.
Seltsamerweise ist ein Rechner besonders haeufig betroffen. Es hilft bisher ein Reboot (daraus folgend ein FSCK). Ich habe fuer Postfix und Antivir jeweils eine eigene Partition. Von den volllaufenden Mounts ist meistens die von Antivir betroffen.

Ich konnte das ganze auf einer Testinstallation nicht nachstellen..
Irgendwo habe ich die Vermutung, dass es seit dem Update auf 4.11 auftritt. Insgesamt laufen diese Maschinen seit 4 Jahren (immer auf das jeweilge aktuelle 4.x geupdatet) Da ja jetzt die EOL von der Version ansteht, hoffe ich, dass es mit einer neuen Version getan ist. Was habt ihr denn fuer eine Version am laufen ?

Viele Gruesse, Ulli