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
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
