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

[Chip]

On 07/29/2016 12:56 PM, Simon McVittie wrote:
> 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.
>
A wise analysis.  It makes sense.  Now, I'm not a startup maven and 
systemd is certainly very new to me.  How would you suggest I correct 
this?  And I believe, yes, network must be operating before 
dnscrypt-proxy activates.  I'm guessing that some configuration file in 
/etc/systemd/system/ needs tweaking?

/etc/ystemd/system/ contains:

bluetooth.target.wants                      hibernate.target.wants
bootdlog.service hybrid-sleep.target.wants
chip-startupdnscryptproxy.service           multi-user.target.wants
dbus-org.bluez.service network-online.target.wants
dbus-org.freedesktop.Avahi.service          paths.target.wants
dbus-org.freedesktop.ModemManager1.service  printer.target.wants
dbus-org.freedesktop.nm-dispatcher.service  shutdown.target.wants
dbus-org.freedesktop.thermald.service       sockets.target.wants
default.target.wants                        suspend.target.wants
display-manager.service                     sysinit.target.wants
display-manager.service.wants               syslog.service
getty.target.wants                          timers.target.wants

multi-user.targets.wants contains:

anacron.service                    NetworkManager.service
avahi-daemon.service               openvpn.service
binfmt-support.service             php7.0-fpm.service
cron.service                       pppd-dns.service
cups-browsed.service               remote-fs.target
cups.path                          rsyslog.service
dns-clean.service                  snapd.refresh.timer
dnscrypt-proxy-resolvconf.service  snapd.service
dnscrypt-proxy.service             systemd-resolved.service
ModemManager.service               thermald.service
networking.service                 ufw.service