Fedora Account System
Red Hat Associate
Red Hat Customer
See https://bugzilla.redhat.com/show_bug.cgi?id=2417958 Problem: Server got updated from F41 to F42. Name : NetworkManager Epoch : 1 Version : 1.50.3 Release : 1.fc41 Name : NetworkManager Epoch : 1 Version : 1.52.1 Release : 1.fc42 On F41 ipv6 was rdy when httpd was started, on F42 it is NOT RDY in time. Ipv6 is rdy when the admin after the reboot is login in with ssh. A restart of http is than working. This means, as ipv4 is rdy, ipv6 must be delayed and in this case, it is a hardcoded fixed ip address. There is no DHCP involved: [connection] id=ens18 uuid=4c1ca25d-6331-3fd3-a0cc-b5950f8ec66e type=ethernet autoconnect-priority=-999 interface-name=ens18 timestamp=1748724092 [ethernet] [ipv4] method=manual address1=a/27,gw1 address2=b/27,gw2 [ipv6] addr-gen-mode=default address1=x/64,x:1 address2=y/64 method=manual [proxy] I replaced the real ip addresses, they don't matter. As the server is a production system, we can't do tests there. Reproducible: Always Actual Results: ipv6 is delayed on boot
> On F41 ipv6 was rdy when httpd was started, on F42 it is NOT RDY in time. If you have services binding to the IPv6 address, you need to set "[ipv6] may-fail=false" in the NM connection. This is documented in "man NetworkManager-wait-online" and "man nm-settings". There was no change in this regard from F41 to F42; perhaps it used to work only due to timing.
The old NetworkManager 1.50.x did not have this issue in general. Maybe some handling changed too? Nope.. NO CHANGE: [ipv6] addr-gen-mode=default may-fail=false address1=2a02....... address2=2a02....... method=manual Dez 01 13:45:35 s129.resellerdesktop.de httpd[965]: (99)Cannot assign requested address: AH00072: make_sock: could not bind to address [2a02....]:80 Dez 01 13:45:35 s129.resellerdesktop.de httpd[965]: no listening sockets available, shutting down Dez 01 13:45:35 s129.resellerdesktop.de httpd[965]: AH00015: Unable to open logs • When a device reaches the activate state depends on its configuration. For example, with a profile that has both IPv4 and IPv6 enabled, by default, NetworkManager considers the device as fully activated already when only one of the address families is ready. The ipv4.may-fail and ipv6.may-fail settings control this behavior. Additionally, the following settings influence when the two address families complete: ipv4.required-timeout, ipv6.required-timeout, ipv4.dhcp-timeout, and ipv6.ra-timeout. For details, see nm-settings-nmcli(5).
Does the httpd service require "network-online.target" via "Want=" and orders after it with "After="? Is NetworkManager-wait-online.service enabled?
● NetworkManager-wait-online.service - Network Manager Wait Online Loaded: loaded (/usr/lib/systemd/system/NetworkManager-wait-online.service; enabled; preset: enabled) Drop-In: /usr/lib/systemd/system/service.d └─10-timeout-abort.conf Active: active (exited) since Mon 2025-12-01 13:45:35 CET; 1h 42min ago HTTPD: I checked, its the normal httpd.service file, not an old one. [Unit] Description=The Apache HTTP Server Wants=httpd-init.service After=network.target remote-fs.target nss-lookup.target httpd-init.service Documentation=man:httpd.service(8) ... [Install] WantedBy=multi-user.target
> After=network.target remote-fs.target nss-lookup.target httpd-init.service There is no "After=network-online.target" ? Then httpd can start before NetworkManager has configured the addresses on the interface. See this from "man httpd.service": Starting the service at boot time The httpd.service and httpd.socket units are disabled by default. To start the httpd service at boot time, run: systemctl enable httpd.service. In the default configuration, the httpd daemon will accept connections on port 80 (and, if mod_ssl is installed, TLS connections on port 443) for any configured IPv4 or IPv6 address. If httpd is configured to depend on any specific IP address (for example, with a "Listen" directive) which may only become available during start-up, or if httpd depends on other services (such as a database daemon), the service must be configured to ensure correct start-up ordering. For example, to ensure httpd is only running after all configured network interfaces are configured, create a drop-in file (as described above) with the following section: [Unit] After=network-online.target Wants=network-online.target
this does not explain, why ipv4 works, and ipv6 not. I will test it later, see if it helps.
btw: it does not make sense to start a webserver if there is no network to serve to. I suggest to add that dependency as a default, if they work.
(In reply to customercare from comment #6) > this does not explain, why ipv4 works, and ipv6 not. I will test it later, > see if it helps. The difference could be that IPv4 addresses are configured immediately; for IPv6 addresses, kernel needs to perform DAD (duplicate address detection) before they can be used by httpd, which takes a couple of seconds. > I suggest to add that dependency as a default, if they work. If the HTTP server is not binding to a specific address, no dependency is needed. Anyway, if you think a dependency is missing in httpd, please reassign this ticket to a different component.
httpd fix seems to work.. I will switch the component to httpd, but i still think it's an NM >1.50.x issue, because it did not happen before the upgrade.
I added the suggested : [Unit] After=network-online.target Wants=network-online.target in this way : [Unit] Description=The Apache HTTP Server (prefork MPM) After=syslog.target network.target remote-fs.target nss-lookup.target network-online.target Wants=network-online.target As we have custom services files for apache.
This is expected and documented exactly as Beniamino explains in comment 5 and comment 8.