[Pkg-systemd-maintainers] Systemd & DNS resolution

Michael Biebl biebl at debian.org
Thu Feb 27 20:11:18 GMT 2014


Hi,

Am 26.02.2014 08:41, schrieb Michael Stapelberg:
> Tomasz Buchert <tomasz.buchert at inria.fr> writes:
>> I have this bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739363
>>
>> There are two issues:
>>
>>   1) how can I wait for DNS resolution to be available before
>>      running my service? (this causes the bug above)
> You shouldn’t, ideally. Services should be able to deal with changes in
> network configuration, such as ethernet interfaces
> appearing/disappearing and global connectivity showing up/getting lost
> at any point in time. I realize that it’s not always easy to fix
> services in that regard, but it’s a good idea to do it.

By not relying on some static dependency during boot, but handling this
dynamically in your service, you make your software more robust.
E.g. you could try the name resolution on startup, if it fails schedule
a retry (optionally with exponential back-off). If after a certain
timeout the name resolution still fails, you could make your service
fail or fall back to a static IP. Knowledge like that is best encoded in
the service itself.

In general, this problem is hard to describe. "name resolution being
available" can mean different things depending on the setup.
In some cases name resolution is done by a local DNS server (or other
services hooked into NSS), in most cases it is probably done by a remote
DNS server. Which leads to the problem that there is no reliable way to
describe "network up" or "remote DNS server reachable".
network might actually be up, but the remote DNS server might be down.
I guess you get the problem.

You might have a look at [0] going into more detail

> That said, you could use After=NetworkManager-wait-online.service with
> the caveat that it only works for NetworkManager users.

Directly ordering after NetworkManager-wait-online.service is not
something you should do. NetworkManager-wait-online.service will pull in
network.target (or network-online.target in newer version).

So using After=network.target is probably better (or the new
network-online.target [1]) if you want to express that your service
needs network access.
This is not yet hooked up properly in Debian though and still needs some
work.

There is also nss-lookup.target [1] (the equivalent to LSB's $named
facility).

You might do a combination of both: Use After=network.target (and
eventuall nss-lookup.target) *and* make your service more fail safe in
cases it can't resolve the name.

HTH,
Michael

[0] http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/
[1] man 7 systemd.special
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 884 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20140227/6a8a9baa/attachment-0002.sig>


More information about the Pkg-systemd-maintainers mailing list