Deluge Auto Start systemd deluged.service zeitverzögert und OpenVPN

[3st]

Servus.

Ich habe Deluge 1.3.13 auf dem Raspberry pi installiert.

OS: Raspbian Jessie Lite
Version: January 2017
Kernel version: 4.4

Gestartet wird es Automatisch über systemd beim booten ... Ich bräuchte jetzt aber eine Möglichkeit damit OpenVPN zuerst gestartet wird und danach erst (~5minuten) der deluge.service und deluge-web.service ... gibt es da irgendwo eine Einstellung im systemd für die einzelnen Starts/Verzögerungen ?

/etc/systemd/system/deluged.service

Spoiler

[Unit]
Description=Deluge Bittorrent Client Daemon
After=network-online.target

[Service]
Type=simple
User=pi
Group=pi
UMask=007

ExecStart=/usr/local/bin/deluged -d

Restart=on-failure

# Configures the time to wait before service is stopped forcefully.
TimeoutStopSec=300

[Install]
WantedBy=multi-user.target

/etc/systemd/system/deluge-web.service

Spoiler

Unit]
Description=Deluge Bittorrent Client Web Interface
After=network-online.target

[Service]
Type=simple

User=deluge
Group=deluge
UMask=027

ExecStart=/usr/local/bin/deluge-web

Restart=on-failure

[Install]
WantedBy=multi-user.target

Ich habe jetzt das mal versucht über die Timer zu lösen aber irgendwie funktioniert das auch nicht wie ich mir das gedacht habe ..
Nach dem Reboot startet nach wie vor alles...

/etc/systemd/system/delugedservice.timer

Spoiler

[Unit]
Description=5 Minuten Deluge Bittorrent Client Daemon

[Timer]
OnBootSec=5min
Unit=deluged.service

[Install]
WantedBy=multi-user.target

Und

/etc/systemd/system/delugeweb.timer

Spoiler

[Unit]
Description=5 Minuten Deluge Bittorrent Web

[Timer]
OnBootSec=5min
Unit=deluge-web.service

[Install]
WantedBy=multi-user.target

Komme da irgendwie gerade nicht weiter ... vlt findet sich hier ja jemand

 

[sia]

Ich bräuchte jetzt aber eine Möglichkeit damit OpenVPN zuerst gestartet wird und danach erst (~5minuten) der deluge.service und deluge-web.service ... gibt es da irgendwo eine Einstellung im systemd für die einzelnen Starts/Verzögerungen ?

Ja, so:

[Unit]
[…]
After=network-online.target openvpn@meinvpn.service
[…]

Relevant:

You do not have permission to view link please Anmelden or Registrieren

 

[Metal_Warrior]

Grade wenn man nur eine Verzögerung eines einzigen Dienstes haben möchte, ohne zu wissen, worauf man genau wartet (ich hab das Problem mit NTP gehabt, weil network-online.target beim Raspi zu früh aktiv wird), kann man auch in der [Service]-Sektion mit
[src=bash]ExecStartPre=/bin/sleep 5[/src]
arbeiten, das den Start um 5 Sekunden verzögert. Die Zahl lässt sich natürlich beliebig anpassen, es ist der ganz normale Sleep-Befehl aus den CoreUtils. Wichtig an der Stelle ist nur, dass Systemd definitiv wartet, bis das letzte linear ausgeführte ExecStartPre-Statement vollständig erfolgreich abgearbeitet wurde, bevor es den/die eigentlichen ExecStart-Befehle parallelisiert ausführt.

 

[3st]

Danke fein

Mit
[KW]ExecStartPre=/bin/sleep 90[/KW]

Ging es schließlich wollte zwar eigentlich so um die 5 Minuten haben.

Aber ab über 90 sec ist Deluge einfach nicht mehr gestartet und hing irgendwo im Loop

 

[sia]

Das klingt ja ziemlich "hacky", wollen wir hoffen, dass das dauerhaft funktioniert

Würde eher schauen, das über systemd-Abhängigkeiten hinzubekommen – meiner Erfahrung nach ist das zuverlässiger. Wobei die rc.conf ja glaube ich immer noch funktioniert *duck und weg*

 

[Metal_Warrior]

@phre4k: Die Erfahrung kann ich auf Raspis nicht teilen. Wie gesagt, beim NTP-Server muss man nen Workaround hacken, weil bei denen halt das Problem der fehlenden Hardwareuhr ist - und damit startet man jedes System immer am 1.1.1970. Das möchte man natürlich nach dem Boot so schnell wie möglich fixen, aber ntpd frägt erst ein paar Minuten nach Start zum ersten Mal die NTP-Server ab, und systemd-timesyncd ist zwar zuverlässig und macht das direkt zu Anfang, aber in jeder anderen Hinsicht ein unbrauchbarer Ersatz für ntpd.

 

[musv]

Weiß nicht, ob Dir das hier weiterhilft. Ich hatte ein ähnliches Problem mit einem Programm, dass abgeschmiert ist, weil der Login immer fehlschlug, weil das Netzwerk noch nicht vollständig da war.

network-online.target prüft, ob das Netzwerk "up" ist. Es prüft nicht, ob eine Netzverbindung da ist. Dazu nimmt man:

[Unit]
Requires=systemd-networkd.socket
After=systemd-networkd.socket

[Service]
ExecStartPre=/usr/lib/systemd/systemd-networkd-wait-online --interface=wlan0