Red Hat Bugzilla – Bug 921566
httpd does not wait for network start and fails
Last modified: 2013-07-31 21:28:21 EDT
Created attachment 710005 [details] Relevant part of /var/log/messages Description of problem: httpd tries to start too early after boot and fails Version-Release number of selected component (if applicable): httpd-2.2.23-1.fc17.x86_64 How reproducible: always on one computer, never on another computer with fc17 (see details below) Steps to Reproduce: 1. systemctl enable httpd 2. reboot 3. Actual results: httpd does not start but can be started manually without any change in the conf files. This is the output of systemctl: # systemctl status httpd httpd.service - The Apache HTTP Server (prefork MPM) Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled) Active: failed (Result: exit-code) since Wed, 20 Feb 2013 14:55:51 +0100; 11min ago Process: 1017 ExecStart=/usr/sbin/httpd $OPTIONS -k start (code=exited, status=1/FAILURE) CGroup: name=systemd:/system/httpd.service Feb 20 14:55:51 hroch486.icpf.cas.cz httpd[1017]: (99)Cannot assign requested address: make_sock: could not bind ...2:80 Feb 20 14:55:51 hroch486.icpf.cas.cz httpd[1017]: no listening sockets available, shutting down Feb 20 14:55:51 hroch486.icpf.cas.cz httpd[1017]: Unable to open logs # systemctl start httpd # systemctl status httpd httpd.service - The Apache HTTP Server (prefork MPM) Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled) Active: active (running) since Wed, 20 Feb 2013 15:07:13 +0100; 1s ago Process: 2805 ExecStart=/usr/sbin/httpd $OPTIONS -k start (code=exited, status=0/SUCCESS) Main PID: 2806 (httpd) CGroup: name=systemd:/system/httpd.service ├ 2806 /usr/sbin/httpd -k start ├ 2808 /usr/sbin/httpd -k start ├ 2809 /usr/sbin/httpd -k start ├ 2810 /usr/sbin/httpd -k start ├ 2811 /usr/sbin/httpd -k start ├ 2812 /usr/sbin/httpd -k start ├ 2813 /usr/sbin/httpd -k start ├ 2814 /usr/sbin/httpd -k start └ 2815 /usr/sbin/httpd -k start Expected results: httpd waits till the network is initialized and starts Additional info: The attached file shows that chronyd, bind, squid, and httpd try to start before the network is initialized and fixed IP addresses are assigned. chronyd, bind, and squid can recover and work, httpd reports an error to /var/log/messages and gives up. The computer where it fails have GB ethernet card on board and 10/100 MB ethernet card in PCI. The slower card is not connected, therefore it is not configured and not used. The GB card has 4 IP addresses, httpd contains 3 IP based vhost, all of them listen both on port 80 (http) and on port 443 (https). The fourth IP address is used by squid listening on port 80 (for historic reasons). On another computer I have only one ethernet card with one IP address. At boot chronyd, bind, httpd, as well as squid start normally.
(In reply to comment #0) > Created attachment 710005 [details] > Relevant part of /var/log/messages > > Description of problem: > httpd tries to start too early after boot and fails > > Version-Release number of selected component (if applicable): > httpd-2.2.23-1.fc17.x86_64 > > > How reproducible: > always on one computer, never on another computer with fc17 (see details > below) > > Steps to Reproduce: > 1. systemctl enable httpd > 2. reboot > 3. > > Actual results: > httpd does not start but can be started manually without any change in the > conf files. This is the output of systemctl: > > # systemctl status httpd > httpd.service - The Apache HTTP Server (prefork MPM) > Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled) > Active: failed (Result: exit-code) since Wed, 20 Feb 2013 14:55:51 > +0100; 11min ago > Process: 1017 ExecStart=/usr/sbin/httpd $OPTIONS -k start > (code=exited, status=1/FAILURE) > CGroup: name=systemd:/system/httpd.service > > Feb 20 14:55:51 hroch486.icpf.cas.cz httpd[1017]: (99)Cannot assign > requested address: make_sock: could not bind ...2:80 > Feb 20 14:55:51 hroch486.icpf.cas.cz httpd[1017]: no listening sockets > available, shutting down > Feb 20 14:55:51 hroch486.icpf.cas.cz httpd[1017]: Unable to open logs > > # systemctl start httpd > > # systemctl status httpd > httpd.service - The Apache HTTP Server (prefork MPM) > Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled) > Active: active (running) since Wed, 20 Feb 2013 15:07:13 +0100; 1s > ago > Process: 2805 ExecStart=/usr/sbin/httpd $OPTIONS -k start > (code=exited, status=0/SUCCESS) > Main PID: 2806 (httpd) > CGroup: name=systemd:/system/httpd.service > ├ 2806 /usr/sbin/httpd -k start > ├ 2808 /usr/sbin/httpd -k start > ├ 2809 /usr/sbin/httpd -k start > ├ 2810 /usr/sbin/httpd -k start > ├ 2811 /usr/sbin/httpd -k start > ├ 2812 /usr/sbin/httpd -k start > ├ 2813 /usr/sbin/httpd -k start > ├ 2814 /usr/sbin/httpd -k start > └ 2815 /usr/sbin/httpd -k start > > > Expected results: > httpd waits till the network is initialized and starts > > Additional info: > The attached file shows that chronyd, bind, squid, and httpd try to start > before the network is initialized and fixed IP addresses are assigned. > chronyd, bind, and squid can recover and work, httpd reports an error to > /var/log/messages and gives up. > > The computer where it fails have GB ethernet card on board and 10/100 MB > ethernet card in PCI. The slower card is not connected, therefore it is not > configured and not used. The GB card has 4 IP addresses, httpd contains 3 IP > based vhost, all of them listen both on port 80 (http) and on port 443 > (https). The fourth IP address is used by squid listening on port 80 (for > historic reasons). > > On another computer I have only one ethernet card with one IP address. At > boot chronyd, bind, httpd, as well as squid start normally. I have created /etc/systemd/system/httpd.service with the following contents: .include /usr/lib/systemd/system/httpd.service [Unit] Requires=NetworkManager-wait-online.service After=NetworkManager-wait-online.service Now httpd waits for network start and works as expected after boot. To be sure I tried also "systemctl restart httpd.service" and it works too. Thus it seems to me that adding this dependency to the unit file will solve the problem.
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.