[systemd-devel] No rhyme or reason to systemd enabling/disabling service

[Simon McVittie]

On 29/07/16 16:59, Chip wrote:
> On 07/29/2016 05:57 AM, Lennart Poettering wrote:
>> My educated guess is that some cyclic dependency or so caused it to
>> not be considered for activation at boot.

Lennart's guess was correct:

> Jul 29 11:33:06 blablabla systemd[1]: basic.target: Found ordering cycle
> on basic.target/start
> Jul 29 11:33:06 blablabla systemd[1]: basic.target: Found dependency on
> sockets.target/start
> Jul 29 11:33:06 blablabla systemd[1]: basic.target: Found dependency on
> dnscrypt-proxy.socket/start
> Jul 29 11:33:06 blablabla systemd[1]: basic.target: Found dependency on
> network.target/start
> Jul 29 11:33:06 blablabla systemd[1]: basic.target: Found dependency on
> NetworkManager.service/start
> Jul 29 11:33:06 blablabla systemd[1]: basic.target: Found dependency on
> dbus.service/start
> Jul 29 11:33:06 blablabla systemd[1]: basic.target: Found dependency on
> basic.target/start
> Jul 29 11:33:06 blablabla systemd[1]: basic.target: Breaking ordering
> cycle by deleting job sockets.target/start

You have asked systemd to do something impossible: basic.target depends
on dnscrypt-proxy.socket, which depends on network.target, which
indirectly depends on basic.target. systemd can't start them all in the
requested order, so it breaks the cycle in an essentially random place.

The bug here is probably that the dnscrypt-proxy.socket *socket* unit
should not depend on anything. You probably intended the corresponding
*service* unit, dnscrypt-proxy.service, to depend on network.target instead?

A socket unit just means systemd is listening on a socket: there's no
reason for it to depend on anything (except perhaps the creation of the
necessary directories, if it's an AF_UNIX socket). If you need the
network to be up before dnscrypt-proxy actually starts, then it's
dnscrypt-proxy.service that needs the dependency.

-- 
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>