KatolaZ <katolaz@???> wrote:

>> For start, we'd just write a small library, that logs to syslog,
>> perhaps maintains some pidfiles (maybe even a *compile-time* option
>> to route directly to libsystemd), then patch up packages that currently
>> use libsystemd to use our new one.
>>
>
> I personally don't see why one would like to redo libsystemd0 from
> scratch, as you seem so kee of doing.
>
> Go on down your path, but I suspect not many people would cheer at you
> in this camp...

I can see the merit - on two points, technical and political.

On the technical side, I can see the usefulness of a system wide standardised service status reporting - making it easy for one process to see if a service it depends on is actually running and ready (as opposed to, "has started"). I have a customer system I've inherited where it regularly fails to startup properly because Asterisk starts before MySQL has finished starting up.
For those of us who put consistency above boot speed, simply changing the init script so MySQL doesn't flag as "started" until the daemon is up and ready to accept requests would fix it; I can see how many would love to be able to have each init script just start and do a "wait for service X to be ready" step, so that init could just fire up all the scripts in parallel and they'd start as each dependency reached the available state.

On the political side, when the Poetteristas say how horrible startup scripts are, and how they don't support parallel/dependency startup - there's be the response that "actually, you don't need all that furball of crap called SystemD because this simple, clean, minimally interlinked, API does it".