KatolaZ <[email protected]> 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".

_______________________________________________
Dng mailing list
[email protected]
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Reply via email to