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

[Andrey Borzenkov]

On Wed, Mar 16, 2011 at 1:23 PM, Michael Biebl <mbiebl at gmail.com> wrote:
> 2011/3/16 Andrey Borzenkov <arvidjaar at mail.ru>:
>> On Wed, Mar 16, 2011 at 1:00 PM, Andrey Borzenkov <arvidjaar at mail.ru> wrote:
>>> On Wed, Mar 16, 2011 at 11:28 AM, Michael Biebl <mbiebl at gmail.com> wrote:
>>>> 2011/3/12 Andrey Borzenkov <arvidjaar at mail.ru>:
>>>>>
>>>>> 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
>>>>
>>>> Some thougths:
>>>>
>>>> - What happens if you have multiple services providing that functionality?
>>>>  Is then foo.target considered started when any or all of those services are up?
>>>
>>> if every service has Before=foo.target - all of them. If services do
>>> not have Before=foo.target - it does not matter who pulls in who.
>>>
>>>> - What happens if you have a service foo.service that "provides"
>>>> bar.target, but also a symlink in bar.target.wants/baz.service?
>>>
>>> Service will be started even if it is deactivated (i.e. systemctl
>>> disable/chkconfig off).
>>
>>
>> Oops, old habits die slowly :) Of course "systemctl disable" will
>> remove this link. So to answer - if foo.service is WnatedBy
>> foo.target, it will *additionally* be started if foo.target is
>> requested to start. Whether foo.service will be started *before* or
>> *after* foo.target is controller by Before/After, which is rather
>> orthogonal to activation trigger.
>>
>>>
>>>> - What if you have a target, say samba.target, which needs to start
>>>> multiple services, say nmb.servic, smbd.service etc?
>>>>
>>>
>>> So let samba.target pull in those services. Where is the problem?
>>>
>>>> Basically, your suggestions only works if you only ever have one
>>>> service that provides the "functionality".
>>>>
>>>
>>> What gives you this impression?
>>>
>>> My suggestion ensures that *if* foo.service that provides
>>> functionality of foo.target is started *then*  foo.target is really
>>> available. Nothing more nothing less. You can continue to pull in
>>> foo.service from foo.target as before. But you already have seen how
>>> confusing it is for administrators. And - how do you decide which
>>> target should pull in e.g. rpcbind.target? You add yet another layer
>>> of indirection for sysadmin to control.  My suggestion simply lessen
>>> learning's curve by ensuring things "just work"
>
> Sorry, but your proposal is stil unclear to me.
> How do describe that e.g. rsyslog.service "provides" syslog.target?
> Do you want to introduce a new Keyword like Provides=syslog.target
> that needs to be added to the rsyslog.service unit file?

No.

rsyslog.service should have

Wants=syslog.target
Before=syslog.target

This ensures that

- if rsyslog.service is started syslog.target will be started also

- syslog.target will become Active only after rsyslog.service has
completed startup.

This ensures that any service that specified After=syslog.target will
be started only after rsyslog.service is started.

For socket activation we would add Wants=syslog.target to
rsyslog.socket, as this is the point where syslog functionality
becomes available.

> Or is rsyslog expected to provide a symlink in syslog.target.wants?
>

This is really orthogonal. As Lennart commented, it may be sensible to
do both. But this symlink does not ensure syslog is actually started
before syslog.target.