[systemd-devel] why do we have aliases fro timedated, resolved, networkd, and what are they good for?

[Zbigniew Jędrzejewski-Szmek]

On Mon, Sep 12, 2016 at 11:55:21AM -0500, Brian Kroth wrote:
> Umut Tezduyar Lindskog <umut at tezduyar.com> 2016-09-12 07:19:
> >Hi Michael,
> >
> >On Sat, Sep 10, 2016 at 1:00 AM, Michael Biebl <mbiebl at gmail.com> wrote:
> >>Hi
> >>
> >>I wonder why we have the following aliases/symlinks
> >>
> >>dbus-org.freedesktop.hostname1.service -> systemd-hostnamed.service
> >>dbus-org.freedesktop.import1.service -> systemd-importd.service
> >>dbus-org.freedesktop.locale1.service -> systemd-localed.service
> >>dbus-org.freedesktop.login1.service -> systemd-logind.service
> >>dbus-org.freedesktop.machine1.service -> systemd-machined.service
> >>dbus-org.freedesktop.network1.service -> systemd-networkd.service
> >>dbus-org.freedesktop.resolve1.service -> systemd-resolved.service
> >>dbus-org.freedesktop.timedate1.service -> systemd-timedated.service
> >>
> >>Those dbus-org.* aliases are used in the corresponding D-Bus system
> >>service files (SystemdService=dbus-org...)
> >>The symlinks/aliases are created statically in $libdir/systemd/system,
> >>so they can't be removed via systemctl disable.
> >>
> >>So, I'm asking myself what good those aliases are for?
> >>They actually have a downside:
> >>We just had a Debian bug report, where a user was masking
> >>systemd-resolved.service, but he was puzzled that he could still
> >>trigger the start of the service via systemd-resolve.
> >>This happened via D-Bus activation and the aliased name (which he had
> >>not masked).
> >
> >AFAIK, that 2 step service file name is for providing a way to prevent
> >dbus activation.
> 
> As in, it was intentionally done this way to allow masking a
> traditional service separately from a dbus activate one?

I think that we should refuse to start a service which is masked,
even if the alias is not masked. This is the general rule which is
expected and followed mostly. Note that the relationship is one-way:
an alias can be masked and this has no effect on "real" service.

Current behaviour sounds like a implementation oversight.

[...]
> For instance, I believe I can declare a service as desired for boot,
> even if I don't know where it's actual .service file is (eg: it's
> generated by legacy sysv init script or some such) by simply adding
> a symlink of
> /etc/systemd/system/multi-user.target.wants.d/foo.service ->
> /bin/true.
Yes, we generally ignore the target of the symlink (as long as
it's not /dev/null).

> >Masking resolved alias file should prevent dbus
> >activation. "systemctl mask dbus-org.freedesktop.resolve1.service".
Yes.

> I think the trouble with that is that it requires enumerating all of
> the symlinks and determining what else might link to another service
> that's masked (via a symlink elsewhere) [...]
No, it's the other way around, see my note above.

Zbyszek