Rechner hängt nach Ausführen von halt.local

[altashveede]

Hallo zusammen,

ich habe in /etc/init.d/halt.local folgendes eingefügt:

umount -lf /mnt
mount /dev/disk/by-id/scsi-SATA_... /mnt
if [ "$?" = 0 ]; then
        echo 'Sicherungspartition eingehängt. Sicherung wird gestartet.'
        rsync -a --delete /home/ /mnt/home.bak/
	if [ "$?" = 0 ]; then
        	echo 'Sicherung durchgeführt.'
	else
		echo 'Sicherung fehlgeschlagen.'
	fi
        umount /mnt
        
else
        echo 'Sicherungspartition nicht eingehängt. Keine Sicherung durchgeführt.'
fi

Das funktionierte unter 11.4 problemlos. Unter 12.1 hängt der Rechner nach dem Abarbeiten dieser Befehle fest, fährt also nicht weiter herunter.

Eine Zeile "shutdown -P now" anzufügen, hätte den Nachteil, dass dann stets der Rechner heruntergefahren wird, auch wenn eigentlich ein Neustart beabsichtigt ist.

Hat jemand eine Idee, wie ich diese Klippe umschiffen kann? Vielen Dank.

 

[spoensche]

Bekommst du eine der Ausgaben, die nach rsync ausgeführt werden angezeigt?

Der rsync Aufruf sollte allerdings auch so aussehen:

rsync -aur --delete /quelle /ziel

 

[altashveede]

Danke, spoensche, für den Hinweis.

Die Ausgabe " Sicherung durchgeführt" wird angezeigt. Und dann passiert nichts mehr. Deine Frage hat mir den Anstoß gegeben, das noch etwas näher zu beobachten. Beunruhigendes Ergebnis: Bei der Ausführung im laufenden Betrieb statt beim Herunterfahren erhielt ich eine andere Ausgabe, nämlich "Sicherung fehlgeschlagen." Das lag an den Rechten für eine Datei, ansonsten wurde die Synchronisierung sauber durchgeführt. Bei der Ausführung während des Herunterfahrens dagegen keine Synchronisierung, aber deren fälschliche Bestätigung und das Festfahren.

Das Ganze hat übrigens mit rsync nichts zu tun. Das gleiche Verhalten tritt auf, wenn ich den rsync Aufruf durch echo 'Hallo Welt!' ersetze. Weiß jemand, von wo halt.local aufgerufen wird? Oder sonstige Ideen?

Als Ausweichlösung könnte ich meine Sicherung wohl mit cron aufrufen. Aber logischer fände ich eigentlich die Ausführung vor dem Herunterfahren. Und bislang funktionierte das ja. :???:

 

[RME]

Hallo,

Wo hangt das script? Mit den echo's solltest Du mehr wissen.

echo "start backup code in halt.local"
echo "do umount -lf /mnt"
umount -lf /mnt
echo "umount -lf /mnt done"
echo "    mount disk"
mount /dev/disk/by-id/scsi-SATA_... /mnt
if [ "$?" = 0 ]; then
echo "mount disk done"
        echo 'Sicherungspartition eingehängt. Sicherung wird gestartet.'
echo "call rsync"
        rsync -a --delete /home/ /mnt/home.bak/
   if [ "$?" = 0 ]; then
      echo 'Sicherung durchgeführt.'
   else
      echo 'Sicherung fehlgeschlagen.'
   fi
echo "call umount /mnt"
        umount /mnt
echo "umount /mnt done"
else
        echo 'Sicherungspartition nicht eingehängt. Keine Sicherung durchgeführt.'
fi
echo "backup code in halt.local done"

Gruss,
Roland

 

[altashveede]

Danke für das Einfügen der Marker-echos. Gemeinerweise wurden die aber alle ausgegeben. Ich habe den Ansatz, die Fehlerursache einzugrenzen, dann mal mit anderen Mitteln, also variieren/auskommentieren weitergeführt. Nach gefühlt hundertmaligem Runter- und Rauffahren des Rechners (bei manuellem Aufruf funktionierte das Skript ja einwandfrei) ließ sich der mount-Befehl eindeutig als Auslöser festmachen. Das habe ich dann auch wieder mit verschiedenen Partitionen und Mountpoints ausprobiert, immer mit demselben Ergebnis, nämlich dem Hängenbleiben beim Herunterfahren.

Vermutung daher, dass bereits vor der vollständigen Abarbeitung von halt.local das Herunterfahren fortgeführt wird. Habe dann noch folgenden Bug-report gefunden -https://bugzilla.novell.com/show_bug.cgi?id=730193-, wobei ich gern zugebe, dass ich die dortige Diskussion nicht bis in die Einzelheiten verstehe. Ich habe aber immerhin die Idee mitgenommen, das Paket systemd-sysvinit durch sysvinit-init zu ersetzen. Damit funktioniert es jetzt wieder.

Herzlichen Dank noch einmal für Eure Unterstützung.

 

[spoensche]

Vermutung daher, dass bereits vor der vollständigen Abarbeitung von halt.local das Herunterfahren fortgeführt wird. Habe dann noch folgenden Bug-report gefunden -https://bugzilla.novell.com/show_bug.cgi?id=730193-, wobei ich gern zugebe, dass ich die dortige Diskussion nicht bis in die Einzelheiten verstehe. Ich habe aber immerhin die Idee mitgenommen, das Paket systemd-sysvinit durch sysvinit-init zu ersetzen.

Das ist eine schlechte Idee. Du solltest systemd-sysvinit nicht ersetzen. sysvinit-init wurde nur zum reproduzieren des Fehlers installiert.


Unterschied zwischen SysvInit und Systemd (Grobfassung):
SysvInit ist das alte Initsystem und hat ca. 20 Jahre u. mehr auf dem Buckel. Folglich kann SysvInit die erforderlichen Aufgaben beim Systemstart nur sequentiell und nicht parallel ausführen. SysvInit ist schlichtweg überholt und wird bald in den wohlverdienten Ruhestand gehen.

Systemd ist ist ein, von RedHat entwickeltes Initsystem. Systemd führt die Aufgaben paralell aus, so dass kein Prozess auf einen anderen warten muss. Folglich ist der Bootvorgang sehr schnell durchgeführt und das System betriebsbereit.

Statt das alte SysvInit zu verwenden, solltest du eine Konfigurartion für den Systemd anlegen, die dein Backup vor halt.local ausführt.

 

[altashveede]

Danke auch für diesen Tip. Ich komme wohl nicht umhin, das Ganze dann doch noch einmal anzufassen.

An der Konfiguration von systemd herumzufummeln scheint allerdings nicht ganz trivial zu sein. So im ersten Wurf habe ich dazu einiges gefunden, aber nichts, was mir konkret weiter hilft. Ich möchte natürlich niemanden als Rechercheassistent einspannen, aber vielleicht hat ja jemand einen guten Artikel zu dem Thema gebookmarkt. Ein entsprechender Hinweis würde mir helfen.

Danke und Gruß

 

[spoensche]

Unter http://www.linux-club.de/viewtopic.php?f=26&t=114724&hilit=kochrezept findest du eine Systemd-Konfig von mir.