Golb Slexa ::

Ich habe ein Shellskript. Dieses wird von mehreren Rechnern und auch von denen ggf. mehrfach aufgerufen.
Und nun möchte ich, dass viele dieser Aufrufe nicht parallel, sondern nacheinander ausgeführt werden - gern in der Reihenfolge des Aufrufs.

In diesem Fall war es ein Wrapper Skript [1], das mit Acme.sh [2] SSL Zertifikate via Let’s Encrypt [3] löst. Man kann ein Ansible [4] Skript parallelisieren: N Server möchten also gleichzeitig vielleicht dasselbe Zertifikat. Nur der erste Aufruf soll ein Zertifikat erstellen und die nachfolgenden Aufrufe, die “vielleicht” dasselbe Zertifikat bearbeitet haben wollen, sollen nicht ebenfalls das Zertifikat erstellen, sondern auf die Ausstellung des ersten Aufrufes warten und dann dessen erstellte Zertifikatsdateien verwenden.
Anm: Let’s Encrypt Live-Server blockieren nach zu vielen Aufrufen für dieselbe Domain für 1 Woche alle Zertifikats-Aktionen, was sehr unangenehm für ein produktives System “sein kann” - auch das möchte ich daher applikatorisch unterbinden.

Ein Queuing will ich nicht bauen oder Semaphoren nutzen. Alles zu kompliziert für diesen Zweck.

Mein Ansatz: die Prozessliste.

Ich baue zunächst eine Funktion - so rein für Wiederverwendungszwecke und/ oder für ein gesourctes Skript mit Funktionen. Aus der Prozessliste per ps -ef filtere ich alle Prozesse, die den Interpreter Bash enthalten und das Shellskript des eigenen Namens $0. Die Prozessliste wird nach der Spalte mit den PIDs numerisch sortiert. Das Filtern mit der Bash ist wichtig, dass nicht andere Prozesse mit demselben Shellskript - z.B. ein offener Editor, der das Skript gerade bearbeitet - versehentlich die echten Abrufe blockieren.

ps -ef | grep "bash.*$0" | grep -v "grep" | sort -k 2 -n

Wenn darin in der ersten Zeile …

[irgendein Kommando] | head -1

… die eigene Prozess ID $$ in der 2. Spalte steht, dann ist der gerade laufende Prozess derjenige mit der kleinsten PID und darf weiterlaufen.
Wenn nicht, gibt es ein sleep für ein paar Sekunden, bevor nochmals getestet wird.

Und so sieht die Funktion _wait_for_free_slot() dann aus:

showdebug=1

# "neverending" loop that waits until the current process is
# the one with lowest PID
function _wait_for_free_slot(){
    local _bWait=true
    typeset -i local _iFirstPID=0
    _wd "--- Need to wait until own process PID $$ is on top ... "
    while [ $_bWait = true ];
    do
        _iFirstPID=$( ps -ef | grep "bash.*$0" | grep -v "grep" | sort -k 2 -n | head -1 | awk '{ print $2}' )
        if [ $_iFirstPID -eq $$ ]; then
            _bWait=false
            _wd "OK. Go!"
        else
            _wd "- all instances"
            test ${showdebug} && ps -ef | grep "bash.*$0" | grep -v "grep" | sort -k 2 -n
            sleep 10
        fi
    done
}

# write debug output if showdebug is set to 1
function _wd(){
        test ${showdebug} && echo "DEBUG: $*"
}

Und dann baue ich in mein Skript jene Funktion _wait_for_free_slot ein - immer dort, wo ich eine sequentielle Ausführung wünsche. Wenn ich dasselbe Skript mit einem Parameter für die Hilfe-Ausgabe starte oder die Liste wartender Instanzen auflisten lasse, dann will ich eigentlich nicht auf die Abarbeitung aller vorherigen Instanzen warten. Naja, ihr seht vielleicht schon, worauf es hinausläuft. Bei jeder Aktion zum Erstellen, Erneuern oder Löschen eines Zertifikats wird die sequentielle Ausführung erzwungen, indem die Funktion _wait_for_free_slot in die erste Zeile geschrieben wird. Und bei den anderen Funktionalitäten lässt man den evtl. parallelisierten Aufruf zu.

#
# pulic function ADD certificate
# 
function add(){
	_wait_for_free_slot

	// actions follow here ...
}

weiterführende Links:

1. IML certman Wrapper für Acme.sh mit DNS Authentication
2. DOCs: os-docs.iml.unibe.ch/iml-certman/
3. Acme.sh Let’ Encrypt Client als Bash Implementierung
4. Let’s Encrypt Kostenlose SSL Zertifikate
5. Ansible Automations Plattform