and people tend to have different ideas what it is supposed to mean. Here are a
couple of ideas people came up with so far:
* The network management software is up.
* All "configured" network interfaces are up and an IP address has been assigned to each.
* All discovered local hardware interfaces that have a link beat have an IP address assigned, independently whether there is actually any explicit local configuration for them.
* The network has been set up precisely to the level that a DNS server is reachable.
* Same, but some specific site-specific server is reachable.
* Same, but "the Internet" is reachable.
* All "configured" ethernet devices are up, but all "configured" PPP links which are supposed to also start at boot don't have to be yet.
* A certain "profile" is enabled and some condition of the above holds. If another "profile" is enabled a different condition would have to be checked.
* Based on the location of the system a different set of configuration should be up or checked for.
* At least one global IPv4 address is configured.
* At least one global IPv6 address is configured.
* At least one global IPv4 or IPv6 address is configured.
* And so on and so on.
All these are valid approaches to the question "When is the network up?", but
none of them would be useful to be good as generic default.
Modern networking tends to be highly dynamic: machines are moved between
networks, network configuration changes, hardware is added and removed, virtual
networks are set up, reconfigured, and shut down again. Network connectivity is
not unconditionally and continuously available, and a machine is connected to
different networks at different times. This is particularly true for mobile
hardware such as handsets, tablets, and laptops, but also for embedded and
servers. Software that is written under the assumption that network
connectivity is available continuously and never changes is hence not
up-to-date with reality. Well-written software should be able to handle dynamic
configuration changes. It should react to changing network configuration and
make the best of it. If it cannot reach a server it must retry. If network
configuration connectivity is lost it must not fail catastrophically. Reacting
to local network configuration changes in daemon code is not particularly
hard. In fact many well-known network-facing services running on Linux have
been doing this for decades. A service written like this is robust, can be
started at any time, and will always do the best of the circumstances it is
running in.
`$network` / `network-online.target` is a mechanism that is required only to
deal with software that assumes continuous network is available (i.e. of the
simple not-well-written kind). Which facet of it it requires is undefined. An
IMAP server might just require a certain IP to be assigned so that it can
listen on it. OTOH a network file system client might need DNS up, and the
service to contact up, as well. What precisely is required is not obvious and
can be different things depending on local configuration.
A robust system boots up independently of external services. More specifically,
if a network DHCP server does not react, this should not slow down boot on most
setups, but only for those where network connectivity is strictly needed (for
example, because the host actually boots from the network).
# FAQ
## How do I make sure that my service starts after the network is *really* online?
That depends on your setup and the services you plan to run after it (see
above). If you need to delay you service after network connectivity has been
established, include
```ini
After=network-online.target
Wants=network-online.target
```
in the `.service` file.
This will delay boot until the network management software says the network is "up".
