Contents

Network connectivity dependencies

Many system services and applications depend on network connectivity. Either
all or some of their functionality requires connection to a local network
and/or the internet.

Some developers tend to think that dependencies should be resolved by the
init system or the service manager (for example systemd or OpenRC).
This only ever worked well for servers with static network configuration. It
never worked well with DHCP. And the demand for dynamic networking features
is much stronger nowadays.

Many of the current network dependency problems cannot be solved in initscripts
or systemd unit files. Certain level of cooperation is expected from the actual
services and applications.

Note: Gentoo's OpenRC has a notion of inactive services. That means NetworkManager
can be running but marked inactive until it activates a successful connection and
switch back to inactive on disconnection. This allows OpenRC to manage basic
dependencies on the connected state. This is AFAIK impossible with systemd.

Passive listening servers

Server processes whose only purpose is to serve clients connecting over the network are
the simplest case. They don't need to depend on network connectivity at all due
to a marvelous invention called wildcard address.

They can start at any time, even before the network configuration service and start
listening for new connections. One of the biggest advantages of this approach is that
it can immediately answer queries from localhost and, as soon as network interfaces
are activated, from local neighbors through link-local addresses.

Long-running clients and peer-to-peer services

Some software is expected to be running the whole time the computer is connected to
the network and actively contact other network hosts. An example of such a software
is ntpd or chronyd on the system level, and telepathy on the session
level.

There are several ways to handle long-running clients:

1) Run them only when global connectivity is available. This is often problematic
as some of the clients could benefit from node-local networking, link-local networking
or even running without network (e.g. ntpd).

2) Run them at startup. Restart them whenever a new connection is established to
force them accomodate the situation. This is how bind is being handled now,
even though it is a server and shouldn't need that at all.

3) Run them at startup, let them follow what's going on. They can use NetworkManager's
D-Bus API, Linux Netlink interface or they could use a more generic library.

Neighbor discovery services

Peer-to-peer discovery services like avahi need to have precise knowledge of what's
going on with the network interfaces and addresses. Their situation is basically
the same as with long-running clients that require solution #3.

Listening servers with connectivity magic

Some servers might need to listen on a non-wildcard address or
require knowledge of network configuration for any other reason. Their
requirements are basically the same as for neighbor discovery daemons
and clients which require solution #3.