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

[Simon McVittie]

On 29/07/16 18:56, Simon McVittie wrote:
> So I'm not sure what you're doing, or
> where your dnscrypt-proxy.{socket,service} came from.

It's a bug in the Debian/Ubuntu packaging for dnscrypt-proxy, which have
their own fork of the systemd units, possibly derived from 1.6.0. I've
opened a bug in the Debian bug tracking system.

-- 
Simon McVittie
Collabora Ltd. 

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Simon McVittie]

On 29/07/16 18:46, Chip wrote:
> 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?

My normal advice would be to talk to dnscrypt-proxy upstream or the
supplier of your dnscrypt-proxy package... but if you're running Ubuntu
16.04, then you should have version 1.6.1, and this bug already appears
to have been fixed before 1.6.1. So I'm not sure what you're doing, or
where your dnscrypt-proxy.{socket,service} came from.

The change you need appears to be
,
and maybe

if that isn't in the version you're running.

It's dnscrypt-proxy.{socket,service} in /usr/lib/systemd/system or
/lib/systemd/system depending on distribution, although you can copy
them into /etc/systemd/system to make local modifications (or use
"drop-ins", see systemd.unit(5)).

-- 
Simon McVittie
Collabora Ltd. 

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [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.wantssuspend.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.serviceNetworkManager.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

Re: [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. 

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Chip]

On 07/29/2016 05:57 AM, Lennart Poettering wrote:

On Thu, 28.07.16 13:44, Chip (jeffsch...@gmail.com) wrote:


Ubuntu 16.04

With no changes to software or anything, on reboot, systemd *sometimes* will
start dnscrypt-proxy.service while other times just ignores it and it fails
to start. There is no rhyme or reason as to why sometimes it starts and
other times fails to start.

All files in /etc/systemd/system/multi-user.target.wants look correct.

I need help troubleshooting this problem.

Following is a successful journalctl -xru dnscrypt-proxy.service, otherwise
when it fails, it simply shows "no results":

My educated guess is that some cyclic dependency or so caused it to
not be considered for activation at boot.

To check that, look at the full boot-up process with "journalctl -b",
and see if your service is mentioned there, in particularly by PID 1.

Lennart


This is what a successful startup looks like:

Jul 29 11:33:06 blablabla systemd[1]: systemd 229 running in system mode.
Jul 29 11:33:06 blablabla systemd[1]: Detected architecture x86-64.
Jul 29 11:33:06 blablabla systemd[1]: Set hostname to .
Jul 29 11:33:06 blablabla kernel: random: nonblocking pool is initialized
Jul 29 11:33:06 blablabla kernel: clocksource: Switched to clocksource tsc
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
Jul 29 11:33:06 blablabla systemd[1]: sockets.target: Job 
sockets.target/start deleted to break ordering cycle starting with 
basic.target/start

Jul 29 11:33:06 blablabla systemd[1]: Listening on Syslog Socket.
Jul 29 11:33:06 blablabla systemd[1]: Listening on fsck to fsckd 
communication Socket.



And then more specifically for successful startup:

ta@blablabla:~$ journalctl -b | grep dnscrypt

Jul 29 11:33:06 blablabla systemd[1]: basic.target: Found dependency on 
dnscrypt-proxy.socket/start
Jul 29 11:33:11 blablabla audit[755]: AVC apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/sbin/dnscrypt-proxy" pid=755 comm="apparmor_parser"
Jul 29 11:33:12 blablabla ureadahead[282]: 
ureadahead:/var/lib/apt/lists/ppa.launchpad.net_anton+_dnscrypt_ubuntu_dists_xenial_main_binary-amd64_Packages: 
No such file or directory
Jul 29 11:33:17 blablabla systemd[1]: Listening on dnscrypt-proxy 
listening socket.
Jul 29 11:33:17 blablabla dnscrypt-proxy[1008]: [INFO] - [okturtles] 
does not support DNS Security Extensions
Jul 29 11:33:17 blablabla dnscrypt-proxy[1008]: [INFO] + Namecoin 
domains can be resolved
Jul 29 11:33:17 blablabla dnscrypt-proxy[1008]: [INFO] + Provider 
supposedly doesn't keep logs
Jul 29 11:33:17 blablabla dnscrypt-proxy[1008]: [NOTICE] Starting 
dnscrypt-proxy 1.6.7
Jul 29 11:33:17 blablabla dnscrypt-proxy[1008]: [INFO] Generating a new 
session key pair

Jul 29 11:33:17 blablabla dnscrypt-proxy[1008]: [INFO] Done
Jul 29 11:33:22 blablabla dnscrypt-proxy[1008]: [INFO] Server 
certificate #809684433 received
Jul 29 11:33:22 blablabla dnscrypt-proxy[1008]: [INFO] This certificate 
is valid
Jul 29 11:33:22 blablabla dnscrypt-proxy[1008]: [INFO] Chosen 
certificate #809684433 is valid from [2016-01-24] to [2017-01-23]
Jul 29 11:33:22 blablabla dnscrypt-proxy[1008]: [INFO] Server key 
fingerprint is 
CB51:0B61:88Y2:FCEB:27CE:56B5:3567:978A:04FF:D9E7:42A4:6A6B:0943:0F0F:F084:656C
Jul 29 11:33:22 blablabla dnscrypt-proxy[1008]: [NOTICE] Proxying from 
127.0.2.1:53 to 23.226.215.93:443

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Lennart Poettering]

On Thu, 28.07.16 13:44, Chip (jeffsch...@gmail.com) wrote:

> Ubuntu 16.04
> 
> With no changes to software or anything, on reboot, systemd *sometimes* will
> start dnscrypt-proxy.service while other times just ignores it and it fails
> to start. There is no rhyme or reason as to why sometimes it starts and
> other times fails to start.
> 
> All files in /etc/systemd/system/multi-user.target.wants look correct.
> 
> I need help troubleshooting this problem.
> 
> Following is a successful journalctl -xru dnscrypt-proxy.service, otherwise
> when it fails, it simply shows "no results":

My educated guess is that some cyclic dependency or so caused it to
not be considered for activation at boot.

To check that, look at the full boot-up process with "journalctl -b",
and see if your service is mentioned there, in particularly by PID 1.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel