Setting "After=network-online.target" for httpd.service will solve the mentioned issue with NetworkManager.service disabled.

PS: The  issue can be fixed from network packages (such as httpd, sshd, etc) side as well. Please let me know / or update affected components.

By default the httpd unit has "After=network.target", which means that
the service is started only after the network target is reached (if
enabled). Actually, network.target has very little meaning during
start-up and is mainly used to ensure a proper ordering during
shutdown [1]. Usually Apache can be started without addresses
configured on the interfaces and so "After=network.target" is enough.

However, when configured to bind to a specific address, Apache requires
the address to be already configured and thus that network connections
are up. In this case, services should order themselves after the
network-online target, which is triggered after network init-scripts
terminate (or after NetworkManager, when it is enabled).

The default setting is to not let services wait for full connectivity,
because in most cases this is not necessary, but this can be easily
modified using a systemd drop-in:

$ cat > /etc/systemd/system/httpd.service.d/override.conf << EOF
[Unit]
After=network-online.target
EOF


The justification for changes in NetworkManager-wait-online unit
mentioned in comment 0 can be found in bug [2] and I don't think there
is anything to change in that regard.

I'm reassigning this to httpd, so that the package maintainer can confirm
whether the manual update to the unit file is necessary when Apache is
configured to bind to a specific address.


[1] https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/
[2] https://bugzilla.gnome.org/show_bug.cgi?id=746039

Lubos, could you please confirm if the mentioned issue is planned to be fixed for httpd component? 

If so, I'll open bugs against some other network services which falls in the same issue (like sshd).

(In reply to dbodnarc from comment #1)
> Setting "After=network-online.target" for httpd.service will solve the
> mentioned issue with NetworkManager.service disabled.

While "After=network-online.target" is the right setting for all services that aren't capable of starting before the network is configured, I don't see how exactly is it related to the situation with disabled NetworkManager.

Plus After=network-online.target is not enough, Wants=network-online.target is needed as well.

http://unix.stackexchange.com/questions/126009/cause-a-script-to-execute-after-networking-has-started/126146#126146

(In reply to Pavel Šimerda (pavlix) from comment #7)
> (In reply to dbodnarc from comment #1)
> > Setting "After=network-online.target" for httpd.service will solve the
> > mentioned issue with NetworkManager.service disabled.
> 
> While "After=network-online.target" is the right setting for all services
> that aren't capable of starting before the network is configured, I don't
> see how exactly is it related to the situation with disabled NetworkManager.

I think it's because the network.service already pulls in and orders
itself before the network-online target:

 [root@rhel-7-3 ~]# systemctl cat network.service | grep network-online
 Before=network-online.target
 Wants=network-online.target

and thus any service with "After=network-online.target" will be
started after init scripts have already configured the interfaces.

If I understood the behavior right, when NetworkManager.service is disabled in rhel73, network.target became inactive (after reboot):
------------------------------------------------------------------------
# systemctl -a | grep network.target
> network.target    loaded    inactive dead      Network
------------------------------------------------------------------------

And here is httpd.service systemd config part also:
------------------------------------------------------------------------
# systemctl cat httpd.service 
# /usr/lib/systemd/system/httpd.service
[Unit]
Description=The Apache HTTP Server
After=network.target remote-fs.target nss-lookup.target
...
------------------------------------------------------------------------

So I think the reason why httpd.service fails to start during boot (with the listening IP address specified) it is network.target inactive.

As far as I understood it is not a bug, but it's a feature.
As for me, the fact that setting httpd service to listen on a IP specific address requires systemd override.conf to be created - was not obvious at all and this wasn't not noted in a man page as well. 

That's why it might be not obvious for other people as well and may require at least some tip in a httpd man page.

Meanwhile I've created solution article regarding this case: 
- https://access.redhat.com/solutions/2815741

Please confirm if I understood everything right and nothing is planned to be fixed in a listed components (httpd/NM).
Thank you in advance

I expect the mentioned behavior to be fixed within recently added BZ#1438749:
> https://bugzilla.redhat.com/show_bug.cgi?id=1438749

We've no intention to make any changes here.  For the minority of configurations which have a dependency on a specific network, a systemd override file should be used as described in Solution 2 of https://access.redhat.com/solutions/2815741