Debian 8 FastD Start Probleme

Heute hat sich bei nem Update auf einem Debian 8 Testsystem FastD v18 auf die Maschine geschlichen mit noch vielen anderen Updates. Leider startet ab jetzt fastd nicht mehr, Grund ist mir nicht ersichtlich denn die Logfiles sind mal wieder so nichts sagend, zu mindestens für mich.

$ sudo service fastd restart
Job for fastd.service failed. See 'systemctl status fastd.service' and 'journalctl -xn' for details.

$ sudo systemctl status fastd.service -l
● fastd.service - Fast and Secure Tunnelling Daemon (connection %I)
Loaded: loaded (/lib/systemd/system/fastd.service; disabled)
Active: failed (Result: resources)

Mai 18 00:24:45 ma-sv01.ffue.eu systemd[1]: [/lib/systemd/system/fastd.service:2] Failed to resolve unit specifiers on Fast and Secure Tunnelling Daemon (connection %I), ignoring: Operation not supported
Mai 18 00:24:45 ma-sv01.ffue.eu systemd[1]: fastd.service failed to run 'start' task: Operation not supported
Mai 18 00:24:45 ma-sv01.ffue.eu systemd[1]: Failed to start Fast and Secure Tunnelling Daemon (connection %I).
Mai 18 00:24:45 ma-sv01.ffue.eu systemd[1]: Unit fastd.service entered failed state.

Das verantwortliche „Startfile“ sieht so aus:

$ sudo cat /lib/systemd/system/fastd.service
[Unit]
Description=Fast and Secure Tunnelling Daemon (connection %I)
After=network.target

[Service]
Type=notify
ExecStart=/usr/bin/fastd --syslog-level info --syslog-ident fastd%I -c /etc/fastd/%I/fastd.conf
ExecReload=/bin/kill -HUP $MAINPID

[Install]
WantedBy=multi-user.target

Hat mit Sicherheit was mit der variable %I zu tun, die Frage ich jetzt wo wird die gesetzt? Denn dort vermute ich den Fehler.

In %I sollte dann wohl hoffentlich der Name der Instanz stehen.
Wo liegt denn Eure fastd.conf?
Ich tippe mal auf einen Fehler und würde in dem /lib/systemd/system/fastd@.service das I mit z.B. „client“ füllen, so dass es passt im Folgenden.

1 Like

Die fast.conf liegt in /etc/fastd/ffue-mesh-vpn/

Hat ja auch bis zum apt-get dist-upgrade auch wunderbar funktioniert. Und ich versuche jetzt zu ergründen was da schief gelaufen ist beim Update. Denn das was mir passiert ist kann ja auch anderen passieren.

zur Info:
das Problem wurde in testing schon am 12.5. behoben, ich habe jetzt Steffen Möller angeschrieben, ob er nicht den Backport aktualisieren kann.

Die fastd.service, die du hier gepostet hast sollte fastd@.service heissen und um /etc/fastd/test zu starten musst die „sudo systemctl start fastd@test“ benutzen.

Mögliche Lösungen:

  • kein Debian benutzen
  • Debian fixen
    • entweder „sudo cp /lib/systemd/system/fastd.service /etc/systemd/systemd/fastd@.service
    • oder „sudo sed /lib/systemd/system/fastd.service 's/%i/test/g' > /etc/systemd/systemd/fastd.service“, wobei „test“ durch den Namen der Konfiguration zu ersetzen ist
1 Like

Egal wie man es macht, beim übernächsten sysupgrade ist’s vermutlich wieder dahin, wenn man nicht aufpasst.

Nein, /etc/systemd/system ist der Ordner für den Systemadministrator und überschreibt die services in /lib/systemd/system.

zur Vollständigkeit:
noch besser ist übrigens beides zu haben, aber dann hier vorgeschlagenerweise mit folgendem Inhalt:


fastd.service:

# This is a mostly empty service, but allows commands like stop, start, reload
# to propagate to all fastd@ service instances.

[Unit]
Description=Fastd and Secure Tunneling Daemon
Documentation=man:fastd(1)
Documentation=http://fastd.readthedocs.org/
After=network.target
Wants=network.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/true
ExecReload=/bin/true
WorkingDirectory=/etc/fastd

[Install]
WantedBy=multi-user.target

fastd@.service:

[Unit]
Description=Fast and Secure Tunnelling Daemon (connection %I)
Documentation=man:fastd(1)
Documentation=http://fastd.readthedocs.org/
PartOf=fastd.service
ReloadPropagatedFrom=fastd.service

[Service]
Type=notify
WorkingDirectory=/etc/fastd/%I
ExecStart=/usr/bin/fastd --syslog-level info --syslog-ident fastd@%I -c /etc/fastd/%I/fastd.conf
ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure
RestartSec=5
TimeoutStopSec=5

[Install]
WantedBy=fastd.service

damit hat man dann die Möglichkeit jede Instanz einzeln über fastd@blubber zu starten/stoppen/whatever, aber auch alle (per Symlink/systemctl enable) aktivierten Instanzen auf einmal zu stoppen/starten/whatever :wink:

1 Like