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

Andrey Borzenkov arvidjaar at mail.ru
Wed Mar 16 04:39:28 PDT 2011


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.


More information about the systemd-devel mailing list