Kategorie-Archiv: FreeBSD

Letzte Woche hielt mein Server eine Hiobsbotschaft für mich bereit:

+ahcich0: Timeout on slot 23 port 0
+ahcich0: is 00000000 cs 01800000 ss 00000000 rs 01800000 tfd c0 serr 00000000 cmd 0000f717
+ahcich0: AHCI reset: device not ready after 31000ms (tfd = 00000080)
+ahcich0: Timeout on slot 24 port 0
+ahcich0: is 00000000 cs 01000000 ss 00000000 rs 01000000 tfd 80 serr 00000000 cmd 0000f817
+ahcich0: AHCI reset: device not ready after 31000ms (tfd = 00000080)
+ahcich0: Timeout on slot 24 port 0
+ahcich0: is 00000000 cs 01000000 ss 00000000 rs 01000000 tfd 80 serr 00000000 cmd 0000f817
+(ada0:ahcich0:0:0:0): lost device
+ahcich0: AHCI reset: device not ready after 31000ms (tfd = 00000080)
+ahcich0: Timeout on slot 24 port 0
+ahcich0: is 00000000 cs 03000000 ss 00000000 rs 03000000 tfd 80 serr 00000000 cmd 0000f817
+(ada0:ahcich0:0:0:0): removing device entry
+ahcich0: AHCI reset: device not ready after 31000ms (tfd = 00000080)
+ahcich0: Poll timeout on slot 25 port 0
+ahcich0: is 00000000 cs 02000000 ss 00000000 rs 02000000 tfd 80 serr 00000000 cmd 0000f917

Festplattenausfall! Die betroffene Platte war Teil eines ZFS-Raids aus vier Platten. Entsprechend sah auch die ZFS-Statusmeldung aus:

Checking status of zfs pools:
NAME   SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
pool  7.25T  5.22T  2.03T    72%  1.00x  DEGRADED  -

  pool: pool
 state: DEGRADED
status: One or more devices has been removed by the administrator.
	Sufficient replicas exist for the pool to continue functioning in a
	degraded state.
action: Online the device using 'zpool online' or replace the device with
	'zpool replace'.
  scan: none requested
config:

	NAME                      STATE     READ WRITE CKSUM
	pool                      DEGRADED     0     0     0
	  raidz1-0                DEGRADED     0     0     0
	    13091973070404888760  REMOVED      0     0     0  was /dev/ada0p1
	    ada1p1                ONLINE       0     0     0
	    ada2p1                ONLINE       0     0     0
	    ada3p1                ONLINE       0     0     0

errors: No known data errors

weiterlesen ZFS: Bewährungsprobe→

Heute mal wieder eine Episode aus dem Leben eines Möchtegern-Administrators…
Nachdem mir ja bereits vor einigen Wochen der Geduldsfaden mit fetchmail gerissen ist, war es heute Subversion, oder – um genauer zu sein – dessen BerkeleyDB-Backend. Zum wiederholten Male war die BDB der Meinung, einfach so aus heiterem Himmel die Arbeit niederlegen zu müssen. Dazu muß man wissen, daß gerade das BDB-Backend ziemliche Probleme mit Berechtigungen hat und einfach aufgibt, wenn da mal was nicht paßt. Bemerkbar macht sich dies in Fehlermeldungen über eine korrupte Datenbank mit der Bitte, svnadmin recover oder gar db_recover laufen zu lassen. Interessanterweise ist das bei mir immer ohne direkte Einwirkung von außen passiert.
Nachdem ich bereits beim letzten Ausfall zwei Tage mit meinem gefährlichen Halbwissen gebraucht habe, das Problem zu korrigieren, hat mich dieses Mal die Lust verlassen. Will heißen: Ich habe Subversion aktualisiert und dabei das Backend auf das dateisystembasierte FSFS umgestellt. Als untergeordnete Übungsaufgabe gabs dazu sicherheitshalber ein Wrapperskript, welches das FreeBSD-Ports-System allerdings vergessen hat, zu installieren. Das hat natürlich dazu geführt, daß der Server nicht ganz so starten wollte, wie vorgesehen. Und wieder ein paar streßbedingte Lebensjahre weniger… 🙂
Nachdem auch diese Hürde genommen war, stand dann die Migration des alten Subversion in das neue an. Da das BDB-Backend diesmal nicht mitinstalliert wurde, fiel der direkte Weg aus. Aber zum Glück gibt es ja die segensreiche Erfindung namens „Backup“. Also das jüngste Subversion-Backup herausgesucht und mit svnadmin load eingespielt. Und ich war sehr überrascht, daß das auf Anhieb geklappt hat…

In nächster Zeit wird sich dann zeigen, ob das FSFS-Backend stabiler läuft als sein BerkeleyDB-Pendant.

Auf meinem Server läuft regelmäßig fetchmail, um die Post von meinen diversen E-Mail-Konten einzusammeln. Diese wird dann via procmail verarbeitet und auf IMAP-Ordner verteilt. Nun hat fetchmail jedoch zum wiederholten Male beim Abholen von E-Mails mit Anhang versagt, die auf meinem GMX-Konto gelandet sind. Hat beim ersten Auftreten des Fehlers noch ein Update von fetchmail geholfen, so hatte ich dieses Mal kein Verständnis mehr für das Fehlverhalten. Ein kurzes Google-Consulting lieferte mit getmail eine Alternative. weiterlesen Auf Wiedersehen fetchmail→