After booting, a crapload of services reliably fail to start: httpd, dhcpd, named, and others. All of them come up fine if I manually start them, after boot completes.
Sifting through /var/log/messages, the common thread is that the network is NOT up, when the jobs start:
Jul 5 07:16:41 shorty httpd: (99)Cannot assign requested address: AH00072: make_sock: could not bind to address 216.27.136.223:8443
Jul 5 07:16:41 shorty httpd: no listening sockets available, shutting down Jul 5 07:16:41 shorty httpd: AH00015: Unable to open logs And: Jul 5 07:16:40 shorty dhcpd:Jul 5 07:16:40 shorty dhcpd: No subnet declaration for lan0 (no IPv4 addresses). Jul 5 07:16:40 shorty dhcpd: ** Ignoring requests on lan0. If this is not what
Jul 5 07:16:40 shorty dhcpd: you want, please write a subnet declaration Jul 5 07:16:40 shorty dhcpd: in your dhcpd.conf file for the network segment Jul 5 07:16:40 shorty dhcpd: to which interface lan0 is attached. ** Jul 5 07:16:40 shorty dhcpd: Jul 5 07:16:40 shorty dhcpd: Jul 5 07:16:40 shorty dhcpd: Not configured to listen on any interfaces! Here's bind shutting down before the server reboot: Jul 5 07:14:30 shorty named[1072]: no longer listening on 127.0.0.1#53 Jul 5 07:14:30 shorty named[1072]: no longer listening on 192.168.0.1#53 Jul 5 07:14:30 shorty named[1072]: no longer listening on 216.254.115.190#53Note all the IP addresses that my bind is listening on. Now, here's bind again, when the system comes up after a reboot:
Jul 5 07:16:39 shorty named[1071]: loading configuration from '/etc/named.conf' Jul 5 07:16:39 shorty named[1071]: using default UDP/IPv4 port range: [1024, 65535] Jul 5 07:16:39 shorty named[1071]: using default UDP/IPv6 port range: [1024, 65535] Jul 5 07:16:39 shorty named[1071]: listening on IPv4 interface lo, 127.0.0.1#53
Jul 5 07:16:39 shorty named[1071]: generating session key for dynamic DNS …That's it. Only 127.0.0.1 was up for bind to listen on. Even lan0, 192.168.0.1, isn't up yet.
Sifting through systemd docs, it appears that services that require network availability should state an After dependency on "network-online.target". Wonderful. Can someone explain why, if that's true, only kdump.service appears to explicitly state that dependency?
[root@shorty system]# fgrep -- network-online.target *.target [root@shorty system]# fgrep -- network-online.target *.service kdump.service:After=network.target network-online.target remote-fs.target So, I see two possible explanations:1) network-online.target was introduced in the most recent systemd update. Prior to that, its equivalent functionality was done in some other way, possibly integrated with network.target. The last update unceremoniously introduced network-online.target, with no advance notice, and without any coordination with packages that need to use it, and thus breaking everything.
2) everything was always like that. Everything was always broken, but until the recent systemd update, its internal logic happened to kick things off in the right order. The last update changed some internal scheduling logic, and now everything is broken.
So, how should this mess get fixed? Start filing bugs against all these packages, requesting a change to their systemd service file, to state a dependency on network-online.target?
Attachment:
pgphGNtu8kxLX.pgp
Description: PGP signature
-- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
