Systemd programming part 2: activation and language issues

Nice article, but there are a few statements which seem to be wrong (or at least misleading):

> "systemctl enable nfs" works, but a subsequent "systemctl start nfs" fails
> because rpcbind (which is the new name for portmap) isn't running
Normally, nfs.service would have [Unit] Requires=rpcbind.service, After=rpcbind.service, which would cause rpcbind.service to be started before nfs.service is started. This applies both when nfs.service is started manually, and also when nfs.service is started because it is requires by some target (e.g. nfs.target, which is in turn wanted by multi-user.target, which is in turn wanted by default.target).

> "WantedBy" and "RequiredBy" directives, which are quite different from the
> "Requires" and "Wants" etc. dependency directives. "WantedBy" plays no role
> in determining when to start (or stop) any service. Instead, it is an
> instruction on how to enable a specific unit.
There are two places where WantedBy/RequiredBy can be used. In the [Install] section, they behave like you describe, i.e. they are used to create links when 'systemctl enable' is invoked. In the [Unit] section, they are simply Wants/Requires in the reverse direction. For this latter use, there's no difference between having Wants=B.service in A.service, having WantedBy=A.service in B.service, or having a symlink to B.service created as /etc/systemd/system/A.service.wants/B.service when systemd has loaded all the units.

The reason that those (overlapping) ways of adding dependencies exist is a combination of two factors. Because it often the "wanted" or "required" service that knows about the dependency. E.g. in case of targets, the list of services that the target "wants" is completely arbitrary, so it cannot be part of the T.target configuration and we want to add something like WantedBy=T.target as part of the service file. But systemd loads units lazily, so if we simply install the unit file, we must make sure that systemd will always load it. This is achieved by creating a symlink in the .wants directory, which will cause systemd to also load the service that the symlink points to when it reads the unit that the .wants directory is for. So the equivalency between different ways of expressing dependencies stated in the previous paragraph is only true when those units have actually been loaded.

Also, without actually looking at the units, it's strange that you use "Requisite=nfs-secure.target" and not "Requires=nfs-secure.target" or maybe "RequiredBy=rpc-gssd.service".

I agree totally with your critique of the multitude of systemd dependency types. They have grown somewhat organically over the years, and it would be good to simplify them at some point. Nevertheless, they were not added lightly, but rather in response to usecases found in the wild which were hard to satisfy with existing vocabulary.