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

[Brian Kroth]

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?

That sorta makes sense that you might want to provide that 
flexibility, but it's somewhat counterintuitive to me in this case.

Since the "service" for both is provided by "systemd-resolved.service" I 
would expect that masking the base name would also prevent activation 
through any aliases.


Maybe my confusion here is in how symlinks are handled generally.

I was under the impression that in most cases it was the names of the 
symlink (source in some contexts, target in others), not the contents of 
it's target that really made a difference.


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.

The fact that /bin/true isn't itself a unit file doesn't really matter - 
it's more so the presence of a name that matters.  Now, generally 
symlinking to the actual unit is convenient for humans looking at the 
files, though that can still be confusing due to overrides and the like 
and something like "systemctl cat" should probably be used to avoid 
that.


In other contexts, like this one, I was also under the impression that 
the target of the symlink (eg: systemd-resolved.service) was just a 
placeholder that stood for the name of the desired service to provide an 
alias for and that the contents of the file weren't read at that time, 
but rather they were evaluated to the contents of that service or in 
this case appended as an additional name (eg: 
dbus-org.freedesktop.resolve1.service) to that service (eg: 
systemd-resolved.service) once that target service was read in.  Then in 
the case that it was masked, I'd have expected that placeholder-fill-in 
operation to simply not take place.

Does my description make sense?

Granted, I haven't actually read the code for that to confirm that 
impression, but that was my recollection from reading through gobs of 
man pages and the systemd blog posts a few months ago.


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

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) in order to find all of the other 
possible aliases since once you've masked the underlying service, it can 
no longer tell you what it's aliases are via the "systemctl show 
foo.service | grep ^Names=" command for instance:

# systemctl show systemd-resolved.service | grep ^Names=
Names=systemd-resolved.service
# systemctl cat systemd-resolved.service
# /dev/null

So, then one has to do something like this to find the other services 
that might also be aliases:

# for i in $(systemctl list-unit-files --no-legend | awk '{ print $1 }'); do systemctl show $i 2>/dev/null | grep -q ^Names=.*systemd-resolved && echo "unit-file: '$i' has alias of 'systemd-resolved'"; done

That's just not generally something one would probably consider doing 
when attempting to mask a service.

Cheers,
Brian