ubuntuusers.de

Permanent Fehler von systemd-networkd-wait-online.service

Status: Gelöst | Ubuntu-Version: Ubuntu 22.04 (Jammy Jellyfish)
Antworten |

aXCell

Avatar von aXCell

Anmeldungsdatum:
21. Juli 2023

Beiträge: 19

Wohnort: Flensburg

Hallo zusammen,

seit einiger Zeit (Ich kann leider nicht genau sagen, seit wann, steigt der oben ganennte Dienst immer aus.

Ich nutze Ubuntu 22.04.3 LTS mit allen aktuellen Updates. Da auf dem Server mein ioBroker läuft, ist der über USB angeschlossene Zigbee Coordinator nicht mehr erreichbar und entsprechender Adapter übergibt in der Folge auch die Geräte nicht mehr an mein Homekit.

Nach einiger Recherche habe ich folgende Info, mit der von euch eventuell jemand mehr anfangen kann, als ich, ich muss ganz ehrlich sagen, ich bin da leider nicht sooo tief in der Materie.

systemctl status systemd-networkd-wait-online.service systemd-networkd
ip link

ergibt:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
× systemd-networkd-wait-online.service - Wait for Network to be Configured
     Loaded: loaded (/etc/systemd/system/systemd-networkd-wait-online.service; enabled; vendor preset: disabled)
     Active: failed (Result: exit-code) since Wed 2023-09-20 11:08:53 CEST; 9h ago
       Docs: man:systemd-networkd-wait-online.service(8)
   Main PID: 692 (code=exited, status=1/FAILURE)
        CPU: 4ms

Sep 20 11:06:53 server systemd[1]: Starting Wait for Network to be Configured...
Sep 20 11:08:53 server systemd-networkd-wait-online[692]: Timeout occurred while waiting for network connectivity.
Sep 20 11:08:53 server systemd[1]: systemd-networkd-wait-online.service: Main process exited, code=exited, status=1/FAILURE
Sep 20 11:08:53 server systemd[1]: systemd-networkd-wait-online.service: Failed with result 'exit-code'.
Sep 20 11:08:53 server systemd[1]: Failed to start Wait for Network to be Configured.


● systemd-networkd.service - Network Configuration
     Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled; vendor preset: enabled)
     Active: active (running) since Wed 2023-09-20 11:06:53 CEST; 9h ago
TriggeredBy: ● systemd-networkd.socket
       Docs: man:systemd-networkd.service(8)
   Main PID: 691 (systemd-network)
     Status: "Processing requests..."
      Tasks: 1 (limit: 18888)
     Memory: 2.6M
        CPU: 569ms
     CGroup: /system.slice/systemd-networkd.service
             └─691 /lib/systemd/systemd-networkd

Sep 20 11:06:53 server systemd[1]: Starting Network Configuration...
Sep 20 11:06:53 server systemd-networkd[691]: lo: Link UP
Sep 20 11:06:53 server systemd-networkd[691]: lo: Gained carrier
Sep 20 11:06:53 server systemd-networkd[691]: Enumeration completed
Sep 20 11:06:53 server systemd[1]: Started Network Configuration.
Sep 20 11:08:54 server systemd-networkd[691]: enp2s0: Link UP
Sep 20 11:08:57 server systemd-networkd[691]: enp2s0: Gained carrier
Sep 20 11:08:58 server systemd-networkd[691]: enp2s0: Gained IPv6LL
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 54:bf:64:67:e9:2c brd ff:ff:ff:ff:ff:ff

Wo setze ich an, den Verursacher zu finden und auch zu eliminieren?

Bzw. Was wird zur Lösungsfindung evtl. noch benötigt?

Grüße aus Flensburg und vielen Dank vorab, Alex

// Nachtrag:

Ach so im LOG des Dienstes ist das hinterlegt:

1
2
3
4
5
6
7
11:08 Failed to start Wait for Network to be Configured.
11:08 systemd-networkd-wait-online.service: Failed with result 'exit-code'.
11:08 systemd-networkd-wait-online.service: Main process exited, code=exited, status=1/FAILURE
11:08 Timeout occurred while waiting for network connectivity.
11:06 Starting Wait for Network to be Configured...
Neustart
10:35 Failed to start Wait for Network to be Configured.

lubux

Anmeldungsdatum:
21. November 2012

Beiträge: 14821

aXCell schrieb:

Da auf dem Server mein ioBroker läuft, ...
Wo setze ich an, den Verursacher zu finden und auch zu eliminieren?

Siehe diesen Thread: https://forum.ubuntuusers.de/topic/a-startjob-is-running-for-wait-for-network-to--2/

aXCell

(Themenstarter)
Avatar von aXCell

Anmeldungsdatum:
21. Juli 2023

Beiträge: 19

Wohnort: Flensburg

Danke lubux!

Post mit der Lösung:

Lösung für das Problem:

1. Verzeichnis anlegen:

sudo mkdir /etc/systemd/system/systemd-networkd-wait-online.service.d/

2. Datei erzeugen und mit Texteditor öffnen:

sudo nano  /etc/systemd/system/systemd-networkd-wait-online.service.d/waitany.conf

3. waitany.conf mit folgendem Inhalt füllen:

1
2
3
[Service]
ExecStart=
ExecStart=/lib/systemd/systemd-networkd-wait-online --any -i lo:missing -i eth0:missing -i wlan0:missing --timeout=10 -q

4. Reboot

lubux

Anmeldungsdatum:
21. November 2012

Beiträge: 14821

aXCell schrieb:

[Service]
ExecStart=
ExecStart=/lib/systemd/systemd-networkd-wait-online --any -i lo:missing -i eth0:missing -i wlan0:missing --timeout=10 -q

Die Interfaces eth0 und wlan0 gibt es bei dir nicht, weil:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 54:bf:64:67:e9:2c brd ff:ff:ff:ff:ff:ff

D. h. die Datei (Inhalt) sollte bei dir so sein:

[Service]
ExecStart=
ExecStart=/lib/systemd/systemd-networkd-wait-online --any -i lo:missing -i enp2s0:missing --timeout=10 -q

Mal damit testen.

aXCell

(Themenstarter)
Avatar von aXCell

Anmeldungsdatum:
21. Juli 2023

Beiträge: 19

Wohnort: Flensburg

lubux schrieb:

[...] Mal damit testen.

Danke, diese ganzen fisseligen 2 und 3 Buchstaben/Zahlen "langen" Abkürzungen... 🙄 😠

Komischerweise war auch mit dem Inhalt aus der ersten Option der Dienst wieder aktiv bzw. hat keine Fehlermeldung im Log verursacht. 🤣

// Allerdings wirft der ioBroker jetzt einen Fehler raus (bzw. vorher auch mit der ersten Option), aber das ist eine andere Baustelle, vermute ich.

lubux

Anmeldungsdatum:
21. November 2012

Beiträge: 14821

aXCell schrieb:

Komischerweise war auch mit dem Inhalt aus der ersten Option der Dienst wieder aktiv bzw. hat keine Fehlermeldung im Log verursacht.

Wenn auch die erste Option schon OK war (d. h. keine Fehlermeldung mehr), kann es daran liegen, dass evtl. nur "--any" oder nur "-i lo:missing" oder nur "--timeout= " lediglich erforderlich wäre. Wenn man es genau wissen will, müsste man die benutzten Optionen eingrenzen. "eth0:missing" bzw. "wlan0:missing" stört auch nicht, weil ja gerade "missing" benutzt wird.

aXCell schrieb:

// Allerdings wirft der ioBroker jetzt einen Fehler raus (bzw. vorher auch mit der ersten Option), ...

Nur interessehalber(btw: ... ich benutze ioBroker nicht und kann zu ioBroker nichts beitragen): Welcher Fehler ist das, der jetzt (mit diesem workaround) vom ioBroker kommt?

aXCell

(Themenstarter)
Avatar von aXCell

Anmeldungsdatum:
21. Juli 2023

Beiträge: 19

Wohnort: Flensburg

lubux schrieb:

aXCell schrieb:

// Allerdings wirft der ioBroker jetzt einen Fehler raus (bzw. vorher auch mit der ersten Option), ...

Nur interessehalber(btw: ... ich benutze ioBroker nicht und kann zu ioBroker nichts beitragen): Welcher Fehler ist das, der jetzt (mit diesem workaround) vom ioBroker kommt?

Im Log taucht das auf:

1
2
2023-09-20 23:50:01.919 - error: host.server Caught by controller[1]: [Yahka 72C6] The selected advertiser, "avahi", isn't available on this platform. Reverting to "bonjour-hap"
2023-09-20 23:50:02.409 - warn: host.server instance system.adapter.zigbee.0 terminated due to SIGTERM

Sprich, die Zigbee Geräte sind (waren) nicht verfügbar. Mittlerweile, ist dieser Fehler aber auch wieder weg... 😲

Keine Ahnung, was da passiert ist.

lubux

Anmeldungsdatum:
21. November 2012

Beiträge: 14821

aXCell schrieb:

Mittlerweile, ist dieser Fehler aber auch wieder weg... 😲

Keine Ahnung, was da passiert ist.

Ich denke, die service-unit(s) die von systemd-networkd-wait-online.service abhängig sind, sind jetzt/dann für avahi "zu schnell" gestartet und avahi hatte damit ein "Problem", aber avahi ist ja "lernfähig" und so ist der Fehler wieder weg. 😉

Antworten |