IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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".
For details, see the next question.
## What does "up" actually mean?
The services that are ordered before `network-online.target` define it's
meaning. *Usually* means that all configured network devices are up and have an
IP address assigned, but details may vary. In particular, configuration may
affect which interfaces are taken into account.
`network-online.target` will time out after 90s. Enabling this might
considerably delay your boot even if the timeout is not reached.
The right "wait" service must be enabled:
`NetworkManager-wait-online.service` if `NetworkManager` is used to configure
the network, `systemd-networkd-wait-online.service` if `systemd-networkd` is
used, etc. `systemd-networkd.service` has
`Also=systemd-networkd-wait-online.service` in its `[Install]` section, so when
`systemd-networkd.service` is enabled, `systemd-networkd-wait-online.service`
will be enabled too, which means that `network-online.target` will include
`systemd-networkd-wait-online.service` when and only when
`systemd-networkd.service` is enabled. `NetworkManager-wait-online.service` is
set up similarly. This means that the "wait" services do not need to be enabled