Heute habe ich mich dann doch endlich mal an das Systemd-Thema gewagt. Mehr aus Interesse und "proof of concept" denn aus Notwendigkeit, denn die Rustdesk-Server-Programme sind bei mir bislang nur das eine Mal abgestürzt, so daß ein automatisches Neustarten lassen nicht wirklich ein Thema war.
Als Amateur und Nutzer einer Systemd-freien Distribution war es wieder mal eine hakelige Angelegenheit, immerhin mit Erkenntnisgewinn.
Ich habe mich an einer Anleitung orientiert, die natürlich für Rechner gedacht war.
Es ging schon damit los, daß bei der Fritzbox kein /etc/Systemd/System-Verzeichnis existiert. Das hätte ich wohl "erstellen" können (habe ich auch mal bei einem der vielen Versuche), habe aber letztendlich doch mit /lib/Systemd/System gearbeitet. Die dort vorhandenen .system-Dateien habe ich mir auch mal angeschaut und die Reihenfolge der Einträge z.T. für meine .system-Dateien übernommen.
Desweiteren gibt es bei der Fritzbox systemctl nicht, dort ist es svctl.
Beim ersten Versuch wurden die erstellten Dienste als nicht existent betrachtet.
Dann habe ich erst einmal einiges auskommentiert. Nach vielen Tests hat sich herausgestellt, daß es beim Fritzbox-Systemd die Option "WorkingDirectory" nicht gibt. Dies hat wiederum die gleichen Konsequenzen, die dazu führen, daß ich Symlinks verwende.
Der hbbr-Dienst wurde nämlich schon recht früh in meinen Tests wie erwartet ausgeführt, der hbbs-Dienst hingegen immer als gescheitert angezeigt. Der Dienst zum Öffnen der Ports (der allerdings lediglich auf das Skript verweist) wird als inaktiv angezeigt Das scheint aber ok zu sein.
Letztendlich mußte ich den hbbs-Dienst auch auf ein Skript verweisen lassen, damit er korrekt ausgeführt wird. Ich vermute mal, daß das daran liegt, daß das Fritzbox-System keine WorkingDirectory-Option hat und deshalb hbbs trotz Aufruf über den Symlink in dem Verzeichnis ausgeführt wird, in dem die Binärdatei auch tatsächlich liegt, wo sie aber keine Schreibrechte hat - siehe frühere Einträge. Also habe ich (ungern) den Dienst auf ein Skript verwiesen, das mittels "cd " Befehl dann doch das machen kann, was die wohl die "WorkingDirectory"-Systemd-Option sonst erledigen würde - und zwar die Ausführung der Binärdatei im Verzeichnis des Symlinks und damit in einem Verzeichnis mit Schreibrechten. Damit läuft dann der Dienst auch korrekt.
Das Aufrufen mittels Systemd funktioniert also prinzipiell. Ob dadurch ein Absturz des Rustdek-Servers korrigiert wird, werde ich vermutlich aber nie erfahren, weil das Problem vorher nur einmal aufgetreten ist und ich erst einmal herausfinden muß, ob ein Absturz samt Neustart auch irgendwo festgehalten wird. Das ich zufällig "live" mitbekomme, daß der Dienst auf einmal nicht mehr geht und dann kurz darauf doch wieder (und das keine andere Ursache als Absturz und Neustart des Dienstes) ist wohl unwahrscheinlich.
[Edit]
Ich vergaß irgendwie völlig, daß man ja die aufgerufenen Prozesse per Terminal beenden (kill) und dann beobachten kann (top), daß sie brav wieder gestartet werden - ganz so wie vorgesehen.
[/Edit]
Wie auch immer, vielen Dank für die Tips und Hilfestellungen. Sie haben erst dazu geführt, daß ich das in Erwägung gezogen und mich daran gewagt habe.
Die hbbr.system-Datei sieht (stellvertretend für die anderen beiden) so aus bei mir (der Befehl verweist auf den Symlink in dem Verzeichnis mit Schreibrechten (hbbr braucht aber keine); da das aber nicht wirklich so funktioniert wie gewollt wg. der fehlenden WorkingDirectory-Systemd-Option, hätte ich den Befehl auch auf das /opt/...-Verzeichnis lenken können, in dem die Binärdatei sich tatsächlich befindet):
[Unit]
Description=RustDesk Relay Server.
[Service]
After=network.target
Type=simple
ExecStart=/var/media/ftp/rustdesk-server/hbbr -k _
Restart=always
RestartSec=5
[Install]
WantedBy=multi-user.target
