On a newly installed F24 I have a /home/... directory with a collection of movie files - *.m4v and such, that I want to googlecast to a TV for viewing. I've configured a private httpd setup to display this directory listing when the local machine name is entered in the address line of google-chrome, and when a file is clicked, it plays and can be "cast" to the TV. Neat!
However, when the machine boots (quiet, without rhgb) the messages include [FAILED] Failed to start The Apache HTTP Server. See 'systemctl status httpd.service' for details. and, sure enough, httpd isn't running.
journalctl -b shows this: Jun 27 10:33:17 garfield httpd[1100]: (99)Cannot assign requested address: AH00072: make_sock: could not bind to address 192.168.10.99:80 Jun 27 10:33:17 garfield httpd[1100]: no listening sockets available, shutting down Jun 27 10:33:17 garfield httpd[1100]: AH00015: Unable to open logs ... Jun 27 10:33:17 garfield systemd[1]: httpd.service: Main process exited, code=exited, status=1/FAILURE Jun 27 10:33:17 garfield systemd[1]: Failed to start The Apache HTTP Server. Jun 27 10:33:17 garfield systemd[1]: httpd.service: Unit entered failed state. Jun 27 10:33:17 garfield systemd[1]: httpd.service: Failed with result 'exit-code'.
It can be started manually later, readily enough, with systemctl start httpd but that's a PITA.
So, why could httpd not "make_sock: could not bind to address 192.168.10.99:80" Could it just be that the network isn't up yet? Why isn't httpd more patient and persistent?
This seems like yet another systemd problem. Can anyone suggest how to fix this?
El 28/6/16 a las 11:28, David A. De Graaf escribió:
On a newly installed F24 I have a /home/... directory with a collection of movie files - *.m4v and such, that I want to googlecast to a TV for viewing. I've configured a private httpd setup to display this directory listing when the local machine name is entered in the address line of google-chrome, and when a file is clicked, it plays and can be "cast" to the TV. Neat!
However, when the machine boots (quiet, without rhgb) the messages include [FAILED] Failed to start The Apache HTTP Server. See 'systemctl status httpd.service' for details. and, sure enough, httpd isn't running.
journalctl -b shows this: Jun 27 10:33:17 garfield httpd[1100]: (99)Cannot assign requested address: AH00072: make_sock: could not bind to address 192.168.10.99:80 Jun 27 10:33:17 garfield httpd[1100]: no listening sockets available, shutting down Jun 27 10:33:17 garfield httpd[1100]: AH00015: Unable to open logs ... Jun 27 10:33:17 garfield systemd[1]: httpd.service: Main process exited, code=exited, status=1/FAILURE Jun 27 10:33:17 garfield systemd[1]: Failed to start The Apache HTTP Server. Jun 27 10:33:17 garfield systemd[1]: httpd.service: Unit entered failed state. Jun 27 10:33:17 garfield systemd[1]: httpd.service: Failed with result 'exit-code'.
It can be started manually later, readily enough, with systemctl start httpd but that's a PITA.
So, why could httpd not "make_sock: could not bind to address 192.168.10.99:80" Could it just be that the network isn't up yet? Why isn't httpd more patient and persistent?
This seems like yet another systemd problem. Can anyone suggest how to fix this?
Perhaps this helps you (search in this link for NetworkManager-wait-online) http://forums.fedoraforum.org/showthread.php?t=298983
On Tue, Jun 28, 2016 at 12:37:16PM +0200, Jose Maria Terry Jimenez wrote:
El 28/6/16 a las 11:28, David A. De Graaf escribió:
On a newly installed F24 ...
However, when the machine boots (quiet, without rhgb) the messages include [FAILED] Failed to start The Apache HTTP Server. See 'systemctl status httpd.service' for details. and, sure enough, httpd isn't running.
It can be started manually later, readily enough, with systemctl start httpd but that's a PITA.
Perhaps this helps you (search in this link for NetworkManager-wait-online) http://forums.fedoraforum.org/showthread.php?t=298983
Thank you, Jose Maria Terry Jimenez. Your answer, combined with Sam Varshavchik's, has solved my problem.
It is necessary to fix TWO things:
1) systemctl enable NetworkManager-wait-online
2) Correct the starting criteria for httpd.service: # diff /usr/lib/systemd/system/httpd.service \ /etc/systemd/system/httpd.service 19c19,21 < After=network.target remote-fs.target nss-lookup.target ---
Wants=network-online.target After=network-online.target remote-fs.target nss-lookup.target ## After=network.target remote-fs.target nss-lookup.target
With BOTH fixes, httpd now starts correctly.
-- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://lists.fedoraproject.org/admin/lists/users@lists.fedoraproject.org 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
On Fri, 1 Jul 2016 17:36:35 -0400 David A. De Graaf wrote:
With BOTH fixes, httpd now starts correctly.
I have so many network things fail to start correctly that I just started putting stuff like this in rc.local:
/bin/bash -c 'sleep 5 ; systemctl restart ypbind' > /dev/null 2>&1 < /dev/null & /bin/bash -c 'sleep 15 ; systemctl restart ntpd' > /dev/null 2>&1 < /dev/null & ...
simpler than fixing things "right", and works fine so far :-).
On 07/01/2016 03:14 PM, Tom Horsley wrote:
On Fri, 1 Jul 2016 17:36:35 -0400 David A. De Graaf wrote:
With BOTH fixes, httpd now starts correctly.
I have so many network things fail to start correctly that I just started putting stuff like this in rc.local:
/bin/bash -c 'sleep 5 ; systemctl restart ypbind' > /dev/null 2>&1 < /dev/null & /bin/bash -c 'sleep 15 ; systemctl restart ntpd' > /dev/null 2>&1 < /dev/null & ...
simpler than fixing things "right", and works fine so far :-).
Well, I've never felt NM was designed for anything other than a laptop that moves around on wifi a lot. A lot of the issues you're hitting is NM trying to make up its mind.
My servers and anything that uses fixed IPs use the good ol' netscripts stuff and completely eschews NM.
<soap> NM, journalctl and systemd/systemctl are solutions for problems that never existed except in the minds of the developers of said idiotic code. Just because it's "new" doesn't mean it's "better". It's just far, FAR more complicated and prone to breaking. </soap> ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - Squawk! Pieces of Seven! Pieces of Seven! Parity Error! - ----------------------------------------------------------------------
On Fri, 1 Jul 2016 15:45:24 -0700 Rick Stevens wrote:
A lot of the issues you're hitting is NM trying to make up its mind.
Actually, I still have the network service startup problems with NM disabled and network turned back on, so I still need to restart things in rc.local to make them be reliable :-(.
El 01/07/16 a las 23:36, David A. De Graaf escribió:
Thank you, Jose Maria Terry Jimenez. Your answer, combined with Sam Varshavchik's, has solved my problem.
It is necessary to fix TWO things:
systemctl enable NetworkManager-wait-online
Correct the starting criteria for httpd.service: # diff /usr/lib/systemd/system/httpd.service \ /etc/systemd/system/httpd.service 19c19,21
< After=network.target remote-fs.target nss-lookup.target
Wants=network-online.target After=network-online.target remote-fs.target nss-lookup.target ## After=network.target remote-fs.target nss-lookup.target
With BOTH fixes, httpd now starts correctly.
You're welcome
Best,
David A. De Graaf writes:
On a newly installed F24 I have a /home/... directory with a collection of movie files - *.m4v and such, that I want to googlecast to a TV for viewing. I've configured a private httpd setup to display this directory listing when the local machine name is entered in the address line of google-chrome, and when a file is clicked, it plays and can be "cast" to the TV. Neat!
However, when the machine boots (quiet, without rhgb) the messages include [FAILED] Failed to start The Apache HTTP Server. See 'systemctl status httpd.service' for details. and, sure enough, httpd isn't running.
journalctl -b shows this: Jun 27 10:33:17 garfield httpd[1100]: (99)Cannot assign requested address: AH00072: make_sock: could not bind to address 192.168.10.99:80 Jun 27 10:33:17 garfield httpd[1100]: no listening sockets available, shutting down Jun 27 10:33:17 garfield httpd[1100]: AH00015: Unable to open logs ... Jun 27 10:33:17 garfield systemd[1]: httpd.service: Main process exited, code=exited, status=1/FAILURE Jun 27 10:33:17 garfield systemd[1]: Failed to start The Apache HTTP Server. Jun 27 10:33:17 garfield systemd[1]: httpd.service: Unit entered failed state. Jun 27 10:33:17 garfield systemd[1]: httpd.service: Failed with result 'exit-code'.
It can be started manually later, readily enough, with systemctl start httpd but that's a PITA.
So, why could httpd not "make_sock: could not bind to address 192.168.10.99:80" Could it just be that the network isn't up yet? Why isn't httpd more patient and persistent?
This seems like yet another systemd problem. Can anyone suggest how to fix this?
httpd.service needs to be fixed. I just reported, and had fixed, the same bug with privoxy. See bug 1350097.
Although this is a packaging problem, it's exacerbated by systemd's lackluster documentation, and as a result a large number of packages are broken, and nobody knows about it until the package gets configured to listen on a specific IP address.
Anything that can be configured to listen on a specific IP address CANNOT be:
After=network.target
It must be:
Wants=network-online.target After=network-online.target
On Tue, Jun 28, 2016 at 06:38:17AM -0400, Sam Varshavchik wrote:
David A. De Graaf writes:
On a newly installed F24 ...
However, when the machine boots (quiet, without rhgb) the messages include [FAILED] Failed to start The Apache HTTP Server. See 'systemctl status httpd.service' for details. and, sure enough, httpd isn't running.
It can be started manually later, readily enough, with systemctl start httpd but that's a PITA.
httpd.service needs to be fixed. I just reported, and had fixed, the same bug with privoxy. See bug 1350097.
Although this is a packaging problem, it's exacerbated by systemd's lackluster documentation, and as a result a large number of packages are broken, and nobody knows about it until the package gets configured to listen on a specific IP address.
Anything that can be configured to listen on a specific IP address CANNOT be:
After=network.target
It must be:
Wants=network-online.target After=network-online.target
Thanks, Sam. Apparently systemd cannot properly start a whole bunch of processes. (see 1119787, as well as your 1350097) Now there's mine, as well - 1352139. We'll see what happens...
Unfortunately, I tried your suggested fix, but it didn't work for me. I probably did something wrong; that's easy with systemd.
-
David A. De Graaf -
José María Terry Jiménez -
Rick Stevens -
Sam Varshavchik -
Tom Horsley