Guten Morgen Matthias,zunächst einmal herzlichen Dank für deine Antwort. Ich war so frei und habe deine Ausführungen getestet und bin an der Stelle leider in eine Menge Fehler gerasselt.
Das System wurde in den Urzustand zurück gesetzt und dein Hinweis in die besagte Datei eingetragen.
# Required-Start: mountkernfs open-iscsi # Required-Stop: mountkernfs open-iscsi
Folglich ist durch Anwendung von insserv die Reihenfolge komplett geändert worden. Sieht soweit auch gut aus.
Aber und jetzt kommts. Ich möchte, dass für das Raid ein Filesystemcheck gemacht wird. Grund hierfür ist einfach, dass darauf brisante Daten liegen. Dummerweise wird der Filesystemcheck (ich vermute mal checkfs.sh) vor dem Laden von open-iscsi gemacht. Ich muss dazu sagen, dass ich in der Datei fstab den Mounteintrag gemacht habe.
Ich war so frei und habe für die Datei checkfs.sh ein Override angelegt und gesagt, dass vor dem Check mdadm-raid gestartet sein soll. Diesem Wunsch wurde jedoch nicht entsprochen und die Fehlermeldung erscheint, dass dadurch mehrere Loops erzeugt werden. Neben diesem kleinen Problem kann der Mount des Raids auch nicht klappen, weil die Reihenfolge nicht bedacht wurde. Ich vermute mal, dass mountall.sh das übernimmt. Zumindest startet dieses Skript bedeutend früher als mdadm.raid, wodurch dummerweise für den Mount kein Raid vorhanden ist. Lösung von mir wäre eine ganz einfache. Ich habe einfach den Mount aus der fstab raus genommen und in rc.local eingetragen. Dem schließt sich sogleich noch der manuelle Start von Postgres danach an (auch in der rc.local). Oder man schraubt den LSB-Header richtig.
Weiterhin besteht das Problem beim Start, dass das Raid gelegentlich mal vom Zustand her "resync=pending" ist. Dann muss man manuell ein "readwrite" darauf loslassen und folglich wird das Raid von neuem gesynct. Wenn ich dann darüber nachdenke, dass darauf das Datenverzeichnis von PostgreSQL ist, werd ich ein wenig nervös.
Weiterhin besteht das Problem beim Stop bzw. Neustart, dass unter deiner Konstellation die Reihenfolge zwar richtig ist. Jedoch erfolgt der Unmount vom Raid unter umountfs (wenn ich die Fehlermeldung richtig deute) und zusätzlich dazu gibts ne hässliche Fehlermeldung, dass ein logischer Block vom Raid defekt ist. Dummerweise ist zu diesem Zeitpunkt aber schon das Raid gestoppt (zumindest versucht, klappt aber nicht, weil es gemountet ist) und leider schon die LUNs entzogen, weil open-iscsi schon beendet wurde. In der Hoffnung, es richtig zu deuten, versucht das System etwas zu unmounten, was faktisch eigentlich gar nicht mehr existent ist. Und wenn man dann das System wieder startet, muss das Raid abermals gesynct werden und die Fehlermeldung "resync=pending" besteht (siehe oben).
Daher müsste man an dieser Stelle aus meiner Sicht noch ein Unmount speziell für das Raid machen und dann deine Reihenfolge belassen. Zudem wäre es ratsam, eine Pause zwischen mdadm-raid und open-iscsi einzulegen. Ich hatte halt das Problem, dass das erste von beiden zu langsam ist.
Alles in allem behaupte ich jetzt einfach mal, dass einige Abhängigkeiten nicht sauber durchdacht sind und wir wirklich nen Bug-Report machen sollten.
Zumindest habe ich die zuvor beschriebenen Sachen live erlebt und erlebe sie aktuell gerade wieder. Oder ich raff es einfach nicht mehr :-).
Gruß Michael@Matthias: Ich bin jetzt einfach mal frech und frage ob Du aus der Region UER stammst? Weil eine Person mit deinem Namen in meine Klasse ging.