Bug#837183: systemd: unprivileged call to systemd-resolve starts systemd-resolved even when masked
bpkroth at gmail.com
Mon Sep 12 17:21:49 BST 2016
Felipe Sateler <fsateler at debian.org> 2016-09-10 12:45:
>Control: forwarded -1 https://github.com/systemd/systemd/issues/4122
>On 9 September 2016 at 19:36, Michael Biebl <biebl at debian.org> wrote:
>> Am 10.09.2016 um 00:26 schrieb Michael Biebl:
>>> So, you'll also need to mask that name, i.e
>> is somewhat related.
>> Upstream's position on this is, that masks apply only on that particular
>> name and not for any existing aliases (symlinks)
Thanks for the backstory.
>I interpret upstream's comment differently. They say "any alias
>pointed to it is masked", which (applied to this case) should mean
>that masking dbus-org.freedesktop.resolve1.service should not cause
>systemd-resolved.service to be masked. I would expect the other way
>around to work though: all aliases *should* resolve to the same unit,
>and if that final unit is masked it should not be started.
Right, that's what I was expecting too.
Side complaint: /usr/share/dbus-1/system-services/ is not listed as one
of the directories searched for units in systemd.unit or systemd.service
or any other man page I've been able to find.
I sort of guessed at dbus activation, but didn't see where that would
have been configured since I was expecting all units to live in either
/lib/systemd/, /run/systemd/ or /etc/systemd/ (excluding user units for
this case which make sense to live in /usr/lib/systemd/ to me).
More information about the Pkg-systemd-maintainers