[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Daemontools


> Yes, this is how it should be done.  That way, people can use familiar
> /etc/init.d/package scripts to control the service instead of having to
> learn daemontools. 

I don't agree with that. If people don't want to learn daemontools why they 
are using it? They can use daemontools for dnscache and other 
daemontools-needing software WITHOUT switching init.d-services to 
daemontools. So I don't see a need in those init.d-scripts.

It may be ok if there are init.d-scripts only called by the user, but these 
script are called also by the system on startup. I think this can be an 
error-source. If someone knows daemontools but is not familiar with the crazy 
way it is implemented into debian and such a init script is doing something 
nasty (Like starting the service even if it's marked as "down") the user is 
confused and wonder why debian is calling "svc -u" in some init scripts.

Sorry, I don't see the point why we should "wrap" daemontools with init 
scripts. If you don't want to use daemontools, don't switch to it.

Implementing runlevel-support into daemontools can be done by modifying the 
run-scripts and the svscan init script. There is no need to write 
init.d-wrappers for all daemontools services.

I hope this discussion is not ending in a solution where we mark ALL 
daemontools services as "down" (To prevent svscan to start them 
automatically) and starting them ONLY by init scripts. If you do it in that 
way, you have a clean solution to be compatible to the init.d mechanism but 
you have thrown away the advantages of daemontools.


Reply to: