[systemd-devel] rc-local.service ordering

[Lennart Poettering]

On Tue, 01.03.11 10:34, Andrey Borzenkov (arvidjaar at gmail.com) wrote:

> Historically rc.local was supposed to be run very late (last) in
> startup sequence; and systemd implicitly relies on it (at least, on
> fedora-like systems) implicitly ordering many things "to be done late"
> afetr rc-sysinit.service.
> 
> Looking at startup debug log, this assumption is wrong. There are
> many, way many services, that are started after rc-sysinit. So it
> simply cannot be used as synchronization cheeckpoint (unless we are
> willing to add implicit dependency on it).
> 
> 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.
> Those service are mostly getty and related plymouth.
> 
> Is there any reason those service are not started *after*
> multi-user.target (and stopped immediately before)? This will ensure
> startup is complete; and have additional advantage that plymouth
> shutdown screen will appear before console is covered by shutdown
> messages :)

Well, I do believe that if multi-user.target is reached it should
actually be complete. Thus only very few services are OK to run after
it, for example stuff that does notifications abouth the runlevels and
stuff like this.

I think the rc-local is a broken concept: the semantics of having a
service running after everything else are just broken, and usually just
something people want to do to avoid thinking about ordering.

I mean, by ordering something after rc-local you already make this thing
a contradiction: suddenly rc-local cannot be the last thing anymore. And
what do you do if two or more services are ordered "after everything
else"? I think "catchall" ordering deps with implicit exceptions are
just a broken concept.

I think in a world where we want to emphasize parallelization offering a
hack to disable it completely is a bad idea.

Also note that rc local stuff is actually ordered after all SysV
services by means of SysVStartPriority=99. 

So my take on this all is that we should deemphesize rc-local, and
support it only as distro-specific compat kludge for what was previous
there, offering ordering semantics only relative to old SysV services,
but not making any guarantees for modern services. People should instead
develop their stuff in a way that makes no explicitly configured deps
necessary at all (i.e. by using socket/bus activation), or if that's not
possible just specify the actual deps they need, instead of asking for
"catchall" dependencies.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.