[systemd-devel] [PATCH] service: do not apply SysV ordering to native services

[Andrey Borzenkov]

On Thu, Mar 24, 2011 at 9:57 PM, Michal Schmidt <mschmidt at redhat.com> wrote:
> On Thu, 24 Mar 2011 21:37:12 +0300 Andrey Borzenkov wrote:
>> Yes, you are right. But blindly resetting SysV priority is still wrong
>> - native unit may have defined it as well.
>
> That's a good point. I did not realize "SysVStartPriority=" exists.
>
>> This ordering is applied only for service without LSB headers; you
>> have really many of them.
>>
>> It is still not clear whether this is a bug. We assume that SysV
>> script and service unit with the same provide the same service. So
>> what logically follows, if SysV script claims it needs to be started
>> after this service and does not help with stating functional
>> requirements (LSB headers), systemd have to ensure script gets what it
>> asked for ...
>
> But according to the rule "Native unit hides SysV script completely" we
> should not care what the SysV script wants or which rc.d directory it
> is linked from, given that a native service of the same name exists.
> We'll never execute the SysV script.
>


You have initscript foo that wants to be executed after initscript
bar. Both are old and rely on chkconfig header to order them
correctly.

You replace bar with bar.service. You do not even know that foo
exists. If you now start ignoring numerical order, you may break foo
...

So we still want to know what relative order of bar was. At least I
think it was intentional :)

Of course it assumes that initscript foo and foo.service do the same.
This assumption (if I am correct) should be made more explicit.