[systemd-devel] rc-local.service ordering

[Lennart Poettering]

On Thu, 10.03.11 13:58, Andrey Borzenkov (arvidjaar at gmail.com) wrote:

> 
> 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.

It's a bad example. As the name of this units suggest, it's a hack. This
should really go away.

And in the meantime it might be good enough to move it between
sysinit.target and basic.target.

> 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.

But this is a work-around, not a fix... (not sure I follow the problem
entirely though).

All use cases I see for this are to make hacks and work-arounds
work. But that doesn't make it particularly attractive to me to add
broken hooks for this...

> > 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.

Hmm, interesting. Can you elaborate on that? I don't see why any login
process should care about the runlevel. Which client is this?
 
> > 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.

Well as I see this we should figure out what is going on with this login
process before we come to conclusions... ;-)

Lennart

-- 
Lennart Poettering - Red Hat, Inc.