Moin
wckl hat geschrieben:Vielen Dank für Hinweise.
Ich kann Dein Problem sicher nicht direkt und vollständig lösen, aber ich kann dir Hilfe zur Selbsthilfe leisten. Meiner Meinung nach, solltest Du aber vorher die grundsätzlichen Gegebenheiten von systemd verstehen. Aber vorher dazu ein paar Rahmenbedingungen für meine Selbsthilfe-Lösung.
- Ich verwende Debian Jessie
- Du musst Dich entscheiden, ob Du sysvinit oder systemd benutzt. Ich würde da Eindeutigkeit schaffen und nur noch systemd verwenden
- Meine Lösung berücksichtigt nicht mehr sysvinit. Ich halte sysvinit für obsolet.
- Ich starte und verwalte auch das Netzwerk selber mit systemd, was sich für meine privaten Belange als absolut vorteilhaft erwiesen hat.
- In Abhängigkeit des vorherigen Punktes habe ich natürlich /etc/init.d/networking aus den Runlevels removed
Also, erste Rahmenbedingung ist: Bei mir wird das Netzwerk über
systemd-networkd.service gestartet. Dazu begleitend
systemd-timesyncd.service und
systemd-resolved.service.
Zweitens, weil ich das Netzwerk über systemd starte, kann ich auch
systemd-networkd-wait-online.service verwenden und habe so Eindeutigkeit darüber, dass das Netzwerk verbunden ist, wenn meine Unit gestartet wird. Wenn Du dazu Fragen hast, mach einfach einen neuen Thread auf.
Die folgenden beiden Beispiele zeigen Dir, wie Du ein Programm zu verschiedenen Zeiten in der Bootphase durch systemd starten kannst. Hier in diesen Beispielen ist es beides mal das gleiche Programm (Bash-Script), welches zur Nachverfolgung nur ein Log anlegt... damit man sieht, was passiert ist.
nano /usr/local/bin/started-by-systemd
Code: Alles auswählen
#! /bin/bash
echo "==============================================================================" >>/usr/local/bin/started-by-systemd.log
d=`date +%d-%m-%Y-%H-%M-%S`
echo $d `basename $0`": Programm gestartet. Param:" $1 $2 >>/usr/local/bin/started-by-systemd.log
if [ "$1" == "network" ]; then
echo $(ip addr show | grep eth0 | grep inet) >>/usr/local/bin/started-by-systemd.log
echo "Run as: $USER" >>/usr/local/bin/started-by-systemd.log
fi
exit 0 # Job ends succesful, systemd continues dependent jobs
# exit 1 # Job failed, no dependent jobs
Nun müssen zwei service-units erstellt werden, die beide dieses Programm starten. Das erste startet es einfach ganz am Ende der Bootphase, nachdem alle Start-Jobs durch sind, unmittelbar vor dem GUI. Das zweitet startet das gleiche Programm in Abhängigkeit vom verfügaren Netzwerk.
nano /etc/systemd/system/start-at-last.service
Code: Alles auswählen
[Unit]
Description=Startet als letztes
After=multi-user.target
[Service]
Type=oneshot
ExecStart=/usr/local/bin/started-by-systemd "After mu.target"
[Install]
WantedBy=graphical.target
nano /etc/systemd/system/start-after-network.service
Code: Alles auswählen
[Unit]
Description=Startet bei Netzwerk-Verfügbarkeit
After=systemd-networkd-wait-online.service
Requires=systemd-networkd-wait-online.service
[Service]
Type=oneshot
ExecStart=/usr/local/bin/started-by-systemd "network"
User=thomas
Group=thomas
[Install]
WantedBy=multi-user.target
Dann noch die Rechte für Script und Service-Units setzen:
Code: Alles auswählen
chmod 755 /usr/local/bin/started-by-systemd
chmod 644 /etc/systemd/system/start-at-last.service
chmod 644 /etc/systemd/system/start-after-network.service
chown root:root /usr/local/bin/started-by-systemd
chown root:root /etc/systemd/system/start-at-last.service
chown root:root /etc/systemd/system/start-after-network.service
Wenn Du diese drei Files angelegt hast, kannst Du testen, ob sie funktionieren. Öffne zwei gleichzeitig sichtbare Terminalfenster und starte im ersten:
Code: Alles auswählen
touch /usr/local/bin/started-by-systemd.log
chmod 666 /usr/local/bin/started-by-systemd.log
Dann startest Du im zweiten die permanente Anzeige dieses Logs... damit man sieht, dass was passiert:
Code: Alles auswählen
/usr/bin/tail /usr/local/bin/started-by-systemd.log -n 10 --sleep-interval=2 -f
Nun versuche (wieder) im ersten Terminalfenster nacheinander folgende Starts:
Code: Alles auswählen
/usr/local/bin/started-by-systemd
/usr/local/bin/started-by-systemd 123
/usr/local/bin/started-by-systemd test
/usr/local/bin/started-by-systemd network
systemctl start start-at-last.service
systemctl start start-after-network.service
Bei jedem Aufruf müsstest Du unmittelbar im Trace-Log-Fenster eine Reaktion sehen. Und wenn keine Fehler angezeigt werden, kannst Du jetzt die neuen Jobs einplanen:
Code: Alles auswählen
systemctl enable start-at-last.service
systemctl enable start-after-network.service
Schau Dir nun den Status beider Jobs an:
Code: Alles auswählen
systemctl status start-at-last.service
systemctl status start-after-network.service
Wenn auch jetzt keine Fehler gemeldet wurden, kannst Du den Rechner einmal rebooten und dir dann anschauen, ob alles erfolgreich abgelaufen ist.
Schau Dir erneut den Status verschiedener Jobs nach dem Reboot an:
Code: Alles auswählen
systemctl status start-at-last.service
systemctl status start-after-network.service
systemctl status systemd-networkd.service
systemctl status systemd-timesyncd.service
systemctl status systemd-networkd-wait-online.service
Schau dir weiterhin an, wie Deine neuen Jobs im Boot platziert sind. Dazu generiere eine Anschauungsgrafik... natürlich in
DEIN Homedir:
Die Grafik öffnest Du mit einem Picture-Viewer ... einfach mal über den System-Filemanager versuchen. Ich nutze dazu
gpicview.
Wenn alles funktioniert und Du die Zusammenhänge verstanden hast, planst Du diese beiden Jobs wieder aus und versuchst die neuen Erkenntnisse beim Einplanen von
fetchmail zu nutzen. Aber auch da würde ich das immer zuerst vorher im Terminal manuell testen.... dort muss es funktionieren, bevor ich einen Jobs fest einplane.
Code: Alles auswählen
systemctl disable start-at-last.service
systemctl disable start-after-network.service
Fall es notwendig ist, dass einer der neuen Jobs nach dem Start "verbleibt", weil er ggf. beim Shutdown wieder etwas "ordentlich beenden" muss, muss man ggf. noch
RemainAfterExit=yes berücksichtigen. Aber das würde ich erst bei Bedarf betrachten.
Im Moment weiss ich gar nicht, ob ich noch was vergessen habe.... aber eigentlich solltest Du mit diesem Rüstzeug Dein Fetchmail starten können. Lediglich ein Hinweis noch, falls Du open-ssh-server nutzt... dann wirst in dessen Unit als Abhängigkeit auch systemd-networkd-wait-online.service eintragen müssen... sonst kanns Probleme geben, weil SSH nicht "zurückkommt", wenn das Netz noch nicht steht.