Wie erstellt man eine Start-Datei für systemd?

[dirk11]

Tach!

Ich habe mir noch für sysvinit, ein Init-Script geschrieben. Das Script wird nur in rcS.d ausgeführt und soll bei einem Start des Rechner auf die Datei /var/opt/autoaus.marker prüfen und wenn die existiert selbige löschen, eine Screen-Session starten und diese in den Hintergrund packen; existiert die Datei nicht, soll es einfach nichts machen.

Code: Alles auswählen

#!/bin/sh -e
### BEGIN INIT INFO
# Provides: autoaus.marker
# Required-Start:
# Required-Stop:
# X-Start-Before:
# X-Stop-After:
# Default-Start:	S
# Default-Stop:
# Short-Description:	start a screen after reboot initiated from autoaus script
### END INIT INFO

case "$1" in
  start)
    echo -n "Proof for autoaus.marker... "
    if [ -e "/var/opt/autoaus.marker" ]; then
        rm "/var/opt/autoaus.marker";
        screen -d -m /bin/bash;
    fi
    echo "done."
    ;;
  stop)
    ;;
  close)
    ;;
  restart)
    ;;
  *)
    echo "Usage: $0 start"
    exit 1
esac

exit 0

Theoretisch bin ich der Meinung, dass das Start-Script korrekt ist. In der Praxis habe ich es leider mit sysvinit nicht mehr testen können, weil ich auch den System-Start bei mir auf systemd umgestellt habe (sprich zum Umstellungs-Zeitpunkt existierte das Script schon!). Leider.
Jetzt habe ich das Problem, daß die Datei autoaus.marker von einem anderen Script zwar "vorschriftsmäßig" erstellt wird, das Startscript aber offensichtlich nicht ausgeführt wird, da die Datei /var/opt/autoaus.marker bei laufendem Rechner noch existiert und kein Screen läuft.

Wie bekomme ich es hin, daß das Script auch unter systemd aufgerufen wird? Kann ruhig als allerletztes sein, das ist vollkommen egal.

[JTH]

Wenn du dir wenig Arbeit machen willst: systemd kann auch mit Initscripten umgehen. systemd scheint allerdings das S als Start-Runlevel nicht zu verstehen.

Für nen üblichen Szenario für Start in den Multi-User-Runlevel würd ich das so anpassen:

Code: Alles auswählen

# Default-Start:	2 3 4 5

Anschließend einmal folgendes ausführen:

Code: Alles auswählen

root@pc:~# update-rc.d -f SCRIPTNAME remove
root@pc:~# update-rc.d SCRIPTNAME defaults

Wenn dus nen Tick abrunden willst, wäre folgende Zeile passend:

Code: Alles auswählen

# Required-Start:	$local_fs

Als systemd-Service ließe sich das auch in ~10 Zeilen umsetzen. Ein Schlagwort wäre heir ConditionPathExists.

[MSfree]

Am einfachsten wäre es, die folgenden Zeilen in die Datei /etc/rc.local zu stecken.
/etc/rc.local wird immer ausgeführt, wenn sie vorhanden ist.

Code: Alles auswählen

#!/bin/sh -e
echo -n "Proof for autoaus.marker... "
if [ -e "/var/opt/autoaus.marker" ]; then
  rm "/var/opt/autoaus.marker";
  screen -d -m /bin/bash;
fi
echo "done."

Sollte die Datei nicht existieren, mußt du sie neu anlegen und mit

Code: Alles auswählen

chown root.root /etc/rc.local
chmod 755 /etc/rc.local

asuführbar machen.

[TomL]

Code: Alles auswählen

# ls /etc/systemd/system/screen*
-rw-r--r-- 1 root root 337 2020-06-03 14:25 /etc/systemd/system/screen@.service

Code: Alles auswählen

# cat /etc/systemd/system/screen@.service
[Unit]
Description=thlu:screen@{user}.service:    Start a User-owned persistent Screen
ConditionPathExists=/var/opt/autoaus.marker

[Service]
Type=simple
User=%i
ExecStartPre=/usr/bin/rm /var/opt/autoaus.marker
ExecStart=/usr/bin/screen -DmS autoscreen
ExecStop=/usr/bin/screen -S autoscreen -X quit

[Install]
WantedBy=multi-user.target

Code: Alles auswählen

# systemctl start screen@thomas.service

# ps -aux | grep screen
thomas    6444  0.0  0.0   8744  3132 ?        Ss   14:33   0:00 /usr/bin/SCREEN -DmS autoscreen

Code: Alles auswählen

# systemctl enable screen@thomas.service

Damit die Service-Unit gestartet wird bzw. gestartet werden kann, muss der User 'thomas' vorher die Kontroll-Datei anlegen. Dieser User deshalb, weil die Service-Unit unter dieser UID instanziiert gestartet wird und zum Löschen die entsprechenden Rechte notwendig sind.

Code: Alles auswählen

$ touch /var/opt/autoaus.marker

[dirk11]

Vielen Dank für eure Lösungs-Vorschläge!

Ich werde es zunächst mit dem Vorschlag von @JTH probieren. Der kommt meinem Verständnis am nächsten, da erinnere ich mich auch in Jahren am ehesten dran. rc.local fällt genau aus dem Grund flach, die ist für mich einfach "zu weit weg", als das ich jemals wieder daran denke, dort hinein zu schauen.
Und das systemd-Script von @TomL ist bestimmt auch super, aber ich muss mich da erstmal mit ein wenig Muße einlesen. Die Lösung von JTH ist für mich derzeit die schnellste.

[dirk11]

So. Der Kram funktioniert fast so, wie er hier dokumentiert ist. Sprich, ich habe das Script als sysvinit-Script erstellt und es wird auch mit systemd ausgeführt. Einzige Einschränkung, deshalb das fast:
Es funktioniert nicht im Runlevel "S", sondern nur in den "normalen" 2-5. Warum das so ist: keine Ahnung, aber auf die Idee hat mich auch jemand anderer gebracht, dass die anfängliche Dysfunktionalität bei mir daran lag, dass ich das Script nur in "S" kopiert habe (was vom Sinn her ja vollkommen richtig gewesen wäre).

[TomL]

Es gibt keine Runlevel unter systemd, völlig egal, was im sysv-Script steht. Für das Script wird maschinell eine systemd-Unit erzeugt, der Autogenerator entscheidet, in welchem Target die Unit gestartet wird. Wenn diese damit einhergehende Zufälligkeit unzureichend ist und ggf. deswegen Abhängigkeiten nicht eingehalten sind, sollte man kein sysv-Script verwenden.

[dirk11]

Sorry, aber ich durchschaue den ganzen Poettering-Kram (noch) nicht wirklich.
Ich habe das Start-Script erstellt und einen symlink nach rcS.d erstellt. Es hat keine weiteren Abhängigkeiten, da es ja nur eine temporäre Datei löscht und eine screen-session starten soll. Damit wurde es nicht ausgeführt. Nachdem ich den symlink in rc2-5.d erstellt habe, funktioniert es - wie ich gerade sehe, zur Hälfte: die Screen-session wird nicht gestartet. Hmm. Warum das denn jetzt wieder nicht?

[TomL]

Das funktioniert deswegen nicht, weil der Ablauf fehlerhaft ist. Natürlich wird screen gestartet, aber systemd beendet wegen Fehlern in diesem Prozess alle Parent- und Child-Prozesse nach ca. 90 Sekunden um das System zu schützen. Nimm statt eines fehlerhaften Scriptes und einer autogenerierten Unit die obige Beispiel-Unit, und es funktioniert auf Anhieb. Das Ergebnis des jetzigen Problem kann man sowohl im Journal als auch im Status der autogenerierten Unit nachlesen.

[dirk11]

Geht das präziser? Ich finde nix in irgendwelchen logs. Das System wurde von sysvinit auf systemd umgestellt, da ist sowieso sehr intransparent, wie das jetzt abläuft. Woran soll ich denn erkennen, ob tatsächlich eine Screen-Session gestartet und in den Hintergrund geschoben wurde? Und wieso sollte die dann wieder zwangsbeendet werden?

Vielleicht bin ich ja blöd, aber ich blick's wirklich nicht.