[systemd-devel] Special targets - should they Want or be WantedBy?

[Andrey Borzenkov]

On Sat, Mar 12, 2011 at 3:14 AM, Michael Biebl <mbiebl at gmail.com> wrote:
> 2011/3/12 Michael Biebl <mbiebl at gmail.com>:
>> 2011/3/11 Andrey Borzenkov <arvidjaar at mail.ru>:
>>> On Fri, Mar 11, 2011 at 9:10 PM, Mike Kazantsev <mk.fraggod at gmail.com> wrote:
>>
>>>
>>>> Btw, rsyslog.service seem to be installed into multi-user.target.wants,
>>>> why not syslog.target, which seem to indicate the point where proper
>>>> syslog daemon is running (according to systemd.special(7))?
>>>>
>>>
>>> Actually good question (same as for portmap) - who should pull in
>>> syslog.target then?
>>
>> Yeah, I noticed this myself already. Quite a bit of syslog output
>> ended up in /proc/kmsg during boot because rsyslog was started rather
>> late (via multi-user.target).
>> Afaics, there is not explicit symlink pulling in syslog.target, so I
>> assume it is handled internally by systemd. Lennart?
>
> Turns out, that indeed syslog.target is not automatically started.
> I symlinked syslog.target into multi-user.target.wants and
> rsyslog.service into syslog.target.wants.
>
> Now all services with After=syslog.target are correctly started after
> rsyslog.service.
>
> Lennart, I think we should add those changes to systemd and rsyslog.service.
>

The problem is not limited to syslog and applies to all special
targets that serve as "virtual provides"

Actually I think design should be reversed. The service that
implements this virtual provide (syslog, network, rpcbind, smtp, ...)
should pull in special target. This way you ensure

- when service that provides functionality is started, corresponding
virtual target is started as indication, that functionality is
available

- if there is no service with requested functionality, target is not
available. In other words - target is not faked to be started unless
functionality is available. This allows easy and logical check,
whether syslog (rpcbind, network, ...) was really provided by any
service - if unit is not started, it was not. To round this off,
specials should also refuse manual activation.

That does not apply to all specials; some of them do serve as "virtual
requires" and pull in other services on demand. Think about
bluetooth.target. Although (as Lennart replied regarding network) it
should probably in reality be hci.tagret (or more generically -
bt-device.target) rather than bluetooth.service, as it is exactly what
we want to *pull* - specific driver for BT device. Which - in turn
should pull in bluetooth.target as indication that BT is now
available.

Specials should really be generic statement "this functionality is now
available". Not means to achieve this functionality.