[systemd-devel] rc-local.service ordering

[Andrey Borzenkov]

On Wed, Mar 2, 2011 at 12:35 AM, Lennart Poettering
<lennart at poettering.net> wrote:
> On Wed, 02.03.11 00:07, Andrey Borzenkov (arvidjaar at gmail.com) wrote:
>
>> Have you actually read what I wrote?
>>
>> "Now, I do not care much about rc-sysinit itself. But I do care that
>> services that we want to be started late are *really* started late."
>>
>> Currently I have impression that rc-local is used as synchronization
>> point by explicitly ordering some service after it. My point is
>> exactly that this is wrong and if these service need to be started
>> late (and I really think some of them need to be started late) some
>> other mechanism is required.
>
> Well, which services are those you believe should be started late?

it is not so much about "being started late" as "being executed at
specific event before execution continues".

Trivial example is fedora-sysinit-(un)hack. On initial startup it
creates /etc/.in_sysinit, which is expected to be removed after
basic.target is reached (which loosely corresponds to /etc/rc.sysinit
in the past). The problem is, we do want file to be removed after
everything that basic.target wanted has finished but before anything
ordered after basic.target is started. There is no easy way to do it
now.

or I was just yesterday asked how to start something "after startup is
finished". Of course you can add unit ordered After default.target ...
except that for him it was broken NFS/autofs mount and he could not
login until NFS was restarted. Again - in this case such action would
need to hook after - or rather just before -
systemd-user-sessions.service, but after everything else that is
ordered before is finished.

> getty? prefdm? I think it is sufficient to order them against rc-local,
> since neither service actually needs to be started that late really. I
> see no problem with allowing early logins.

Well, I just found that if completion of default.target job is delayed
(because some service takes too much time e.g.) logins done before
systemd-update-utmp-runlevel has been executed are not entered in wmp.
Apparently system never expected that login was possible before
run-level had been reached.

> In fact I think it is a feature even.

Even if it is, the above is indication that it may be unexpected and
break things in subtle ways.