Arch Linux

Bekomme WakeOnLan auf meinem ARCH-NAS nicht ans laufen

DoXer

Hi,
ich habe ein NAS mit ARCH aufgebaut, Netzwerk ist über feste IP aktiv, das Decive heisst enp0s31f6. NETCTL möchte ich nutzen, da nur feste IP über Ethernet vorhanden ist und ich keine Profile benötige (Keep it simple).
Nun folge ich dem WIKI https://wiki.archlinux.org/index.php/Wake-on-LAN und hab erstmal WakeOnLan mit

/usr/bin/ethtool -s enp0s31f6 wol g

erfolgreich aktiviert. Nun möchte ich das ganze über systemd während des bootens aktivieren.
Nach einem reboot war WakeOnLan natürlcih erstmal wieder aus, getestet mit

ethtool enp0s31f6| grep Wake-on

Dazu also laut Wiki die Datei

/etc/systemd/system/wol@.service

mit folgenden Inhalt erstellt:

[Unit]
Description=Wake-on-LAN for %i
Requires=network.target
After=network.target

[Service]
ExecStart=/usr/bin/ethtool -s %i wol g
Type=oneshot

[Install]
WantedBy=multi-user.target

Ein

systemctl start wol@enp0s31f6.service

hat WakeOnLan aktiviert.

Dann noch mit

systemctl enable wol@enp0s31f6.service

enabled und rebootet. Aber WakeOnLan ist nicht aktiv.
Hier ein Auszug aus dem Journal:

journalctl |grep systemd.*enp

nach dem reboot.

Sep 24 12:58:00 nas systemd-networkd[225]: eth0: Renamed to enp0s31f6
Sep 24 12:58:00 nas systemd-networkd[225]: enp0s31f6: IPv6 successfully enabled
Sep 24 12:58:03 nas systemd-networkd[225]: enp0s31f6: Gained carrier
Sep 24 12:58:04 nas systemd-networkd[225]: enp0s31f6: Gained IPv6LL
Sep 24 12:58:05 nas systemd-networkd[225]: enp0s31f6: Configured
Sep 24 12:58:13 nas systemd[1]: Starting Wake-on-LAN for enp0s31f6...
Sep 24 12:58:13 nas systemd[1]: Started Wake-on-LAN for enp0s31f6.

Der Status ergibt folgendes:

● wol@enp0s31f6.service - Wake-on-LAN for enp0s31f6
   Loaded: loaded (/etc/systemd/system/wol@.service; enabled; vendor preset: disabled)
   Active: inactive (dead) since Sun 2017-09-24 13:18:25 CEST; 3min 37s ago
  Process: 659 ExecStart=/usr/bin/ethtool -s enp0s31f6 wol g (code=exited, status=0/SUCCESS)
 Main PID: 659 (code=exited, status=0/SUCCESS)

Sep 24 13:18:25 nas systemd[1]: Starting Wake-on-LAN for enp0s31f6...
Sep 24 13:18:25 nas systemd[1]: Started Wake-on-LAN for enp0s31f6.

Starte ich nun

systemctl status wol@enp0s31f6.service

ist WOL aktiv, aber eben nicht während des bootens.

Was mache ich falsch?

Gruß
Michael

[gelöscht]

DoXer schriebStarte ich nun
systemctl status wol@enp0s31f6.service
ist WOL aktiv, aber eben nicht während des bootens.

Sehr merkwürdig. Durch die Systemd-Statusabfrage des Dienstes sollte der Service nicht starten.
Daher vermute ich, dass das Starten des Dienstes in diesem Fall nichts mit dem ausgeführten systemctl status zu tun hat.
Ich sehe in der Beschreibung deines Vorgehens des Weiteren nirgendwo ein

systemctl enable wol@enp0s31f6.service

.
Hast du den Service ergo überhaupt für den automatischen Start aktiviert?

DoXer

Ja habe ich enabled, steht oben im Text , habe nur das Kommando nicht explizit eingetragen.

Edit: Habe ich nachgetragen.

DoXer

Hat keiner eine Idee?

[gelöscht]

Was passiert denn, wenn du den Unit-Start verzögerst.
D.h. ein ExecStartPre=/usr/bin/sleep 60 oder so hinzufügst.
Geht es dann?
Falls ja, sind womöglich von ethtool benötigte Ressourcen noch nicht verfügbar.

DoXer

Ja, mit dem Sleep hat es geklappt. Danke...

Sieht jetzt so aus:

[Unit]
Description=Wake-on-LAN for %i
Requires=network.target
After=network.target

[Service]
ExecStartPre=/usr/bin/sleep 30
ExecStart=/usr/bin/ethtool -s %i wol g
Type=oneshot

[Install]
WantedBy=multi-user.target

[gelöscht]

Dann solltest du mal schauen, warum ethtool nicht ohne das warten funktioniert und ggf. eine entsprechende Abhängigkeit hinzufügen.
Das Schlafen für 30 Sekunden ist ja nur ein, womöglich sogar instabiler, Hack.

DoXer

Wie kann ich das herausbekommen? Bin mit systemd noch nicht so vertraut. Komme aus der init.d-Welt 🙂

[gelöscht]

Das müsste ich selbst ergooglen und austesten.
Da ich WOL so nicht benutze kann ich dir da leider nicht weiter helfen.
Mein letzter Beitrag auch nur als Hinweis gemeint und Warnung, dass es womöglich nicht zuverlässig funktioniert, falls die benötigte Ressource mal länger als 30 Sekunden braucht.

Datenschutz
Impressum