# Beta Test linuxmuster.net 7.4 **URL:** \ **Category:** Server\ **Created:** [3. Juni 2026 um 13:47 UTC](https://ask.linuxmuster.net/t/beta-test-linuxmuster-net-7-4/12176 "2026-06-03T13:47:20Z")\ **Posts on this page:** 1\ **Showing post:** 212
**Author:** ![juergen](https://ask.linuxmuster.net/user_avatar/ask.linuxmuster.net/juergen/32/3429_2.png) [@juergen](https://ask.linuxmuster.net/u/juergen)\ **Post date:** [3. September 2026 um 10:17 UTC](https://ask.linuxmuster.net/t/beta-test-linuxmuster-net-7-4/12176/212 "2026-09-03T10:17:25Z")
Hallo @thomas, im Upgrade-Skript `linuxmuster-release-upgrade` habe ich in den Zeilen 163-169, genauer in Zeile 165 einen kleinen Fehler entdeckt: ```bash 163 # disable obsolete services 164 echo -e "\n## Disabling obsolete services..." 165 for s in isc-dhcp-server6 networkd-wait-online.service systemd-resolved; do 166 for c in stop disable mask; do 167 systemctl $c $s 168 done 169 done ``` In Ubuntu 26.04 existiert die Systemd-Unit `networkd-wait-online.service` nicht. Ich denke, da sollte `systemd-networkd-wait-online.service` stehen. Das ist mir aufgefallen, als ich mit ```bash systemctl --failed ``` nach dem Upgrade mir die Systemd-Units ausgeben ließ, die aufgrund eines Fehlers nicht gestartet werden konnten: ```bash UNIT LOAD ACTIVE SUB DESCRIPTION ● systemd-networkd-wait-online.service loaded failed failed Wait for Network to be Online ``` Ein ```bash systemctl status systemd-networkd-wait-online.service ``` gab folgende Fehlermeldung aus: ```bash × systemd-networkd-wait-online.service - Wait for Network to be Online Loaded: loaded (/usr/lib/systemd/system/systemd-networkd-wait-online.service; enabled; preset: enabled) Drop-In: /run/systemd/generator.late/systemd-networkd-wait-online.service.d └─10-netplan.conf Active: failed (Result: exit-code) since Thu 2026-09-03 11:03:58 CEST; 2min 26s ago Invocation: 1b2d3faf7318491db2021d84d845351d Docs: man:systemd-networkd-wait-online.service(8) Process: 1622 ExecStart=/lib/systemd/systemd-networkd-wait-online -i ens18:degraded (code=exited, status=0/SUCCESS) Process: 1634 ExecStart=/lib/systemd/systemd-networkd-wait-online --any --dns -o routable -i ens18 (code=exited, status=1/FAILURE) Main PID: 1634 (code=exited, status=1/FAILURE) Mem peak: 2.1M CPU: 6ms Sep 03 11:03:58 server.domain.tld systemd[1]: Starting systemd-networkd-wait-online.service - Wait for Network to be Online... Sep 03 11:03:58 server.domain.tld systemd-networkd-wait-online[1634]: Failed to connect to io.systemd.Resolve.Monitor: No such file or directory Sep 03 11:03:58 server.domain.tld systemd-networkd-wait-online[1634]: Could not create manager: No such file or directory Sep 03 11:03:58 server.domain.tld systemd[1]: systemd-networkd-wait-online.service: Main process exited, code=exited, status=1/FAILURE Sep 03 11:03:58 server.domain.tld systemd[1]: systemd-networkd-wait-online.service: Failed with result 'exit-code'. Sep 03 11:03:58 server.domain.tld systemd[1]: Failed to start systemd-networkd-wait-online.service - Wait for Network to be Online. ``` Die Fehlermeldung deuted darauf hin, dass die Systemd-Unit `systemd-resolved` nicht gestartet ist, was auch logisch ist, die wurde ja im Update-Skript in den Zeilen 163-169 gestoppt, deaktiviert und maskiert. ## Und jetzt kommt das große ABER: Grundsätzlich halte ich es für keine gute Idee, gewisse Systemd-Units pauschal für obsolet zu betrachten und das aus zwei Gründen: 1. Die beiden Systemd-Units `systemd-networkd-wait-online.service` und `systemd-resolved` sind in Ubuntu integraler Bestandteil und sind standardmäßig gestartet. Durch die Deaktivierung und Maskierung entfernen wir uns vom Standardunterbau. 2. Die Deaktivierung und Maskierung der Systemd-Unit `isc-dhcp-server6.service` ist bei IPv4-only Netzwerken die einzige Möglichkeit, um IPv6-DHCP-Server abzuschalten. Das geht mMn also in Ordnung. Auf die Units `systemd-networkd-wait-online.service` und `systemd-resolved` verlassen sich jedoch andere Systemd-Units. Eine Deaktivierung und Maskierung der beiden Units kann unter Umständen dafür sorgen, dass sich das System nicht so verhält wie vorgesehen. ### Erklärung `systemd-networkd-wait-online.service` ist beispielsweise dazu da, auf eine funktionierende Netzwerkverbindung zu warten. Der Start von Diensten, die eine funktionierende Netzwerkverbindung brauchen, um korrekt starten zu können, kann damit entsprechend verzögert werden. Welche Dienste das konkret sind, kann man sich mit ```bash systemctl list-dependencies systemd-networkd-wait-online.service --reverse ``` ausgeben lassen: ```bash systemd-networkd-wait-online.service ● └─network-online.target ● ├─bittorrent.service ● ├─cups-browsed.service ● ├─isc-dhcp-server.service ○ ├─iscsid.service ○ ├─open-iscsi.service ● └─samba-ad-dc.service ``` Der erfolgreiche Start der Unit `systemd-networkd-wait-online.service` hängt jedoch wie oben bereits erwähnt von `systemd-resolved.service` ab, was uns zum eigentlichen ### Problem führt: Startet man `systemd-resolved.service` mit den Standardeinstellungen kommen sich `systemd-resolved` und `samba-ad-dc` ins Gehege, da `systemd-resolved` seinen **DNS Stub Listener** (noch vor dem Starten von `samba-ad-dc`) an `127.0.0.1:53` bindet, was aber auch `samba-ad-dc` möchte und für die lokale Namensauflösung essentiell ist. Das führt zu folgendem Fehler beim Starten von `samba-ad-dc.service`: ```auto ... Sep 03 11:57:17 server.domain.tld systemd[1]: Starting samba-ad-dc.service - Samba AD Daemon... Sep 03 11:57:17 server.domain.tld systemd[1]: Started samba-ad-dc.service - Samba AD Daemon. Sep 03 11:57:17 server.domain.tld samba[3245]: [2026/09/03 11:57:17.591265, 0] source4/samba/service_stream.c:371(stream_setup_socket) Sep 03 11:57:17 server.domain.tld samba[3245]: stream_setup_socket: Failed to listen on 0.0.0.0:53 - NT_STATUS_ADDRESS_ALREADY_ASSOCIATED Sep 03 11:57:17 server.domain.tld samba[3245]: [2026/09/03 11:57:17.591303, 0] source4/dns_server/dns_server.c:672(dns_add_socket) Sep 03 11:57:17 server.domain.tld samba[3245]: Failed to bind to 0.0.0.0:53 TCP - NT_STATUS_ADDRESS_ALREADY_ASSOCIATED ``` ### Lösung Um zu verhindern, dass `systemd-resolved` seinen Stub-Listener startet, muss man im Verzeichnis `/etc/systemd/resolved.conf.d` die Datei `no-stub.conf` mit folgendem Inhalt erstellen. (Es kann sein, dass das Verzeichnis `/etc/systemd/resolved.conf.d` noch nicht existiert → `mkdir -p /etc/systemd/resolved.conf.d`) ```auto # /etc/systemd/resolved.conf.d/no-stub.conf [Resolve] DNSStubListener=no ``` Ein anschließendes ```auto systemctl restart systemd-resolved.service systemctl restart systemd-networkd-wait-online.service systemctl restart samba-ad-dc.service ``` startet die Dienste in der richtigen Reihenfolge. Auf Systemen, auf denen das Upgrade bereits durchgelaufen ist, muss man **vorher** die beiden System-Units `systemd-resolved.service` und `systemd-networkd-wait-online.service` wieder demaskieren und aktivieren: ```auto systemctl unmask networkd-wait-online.service for s in systemd-resolved.service systemd-networkd-wait-online.service; do for c in unmask enable; do systemctl $c $s done done ``` LG Jürgen --- _[View the full topic](https://ask.linuxmuster.net/t/beta-test-linuxmuster-net-7-4/12176)._