Re: starting service order

[Jan-Henrik Haukeland]

On Jul 6, 2004, at 12:11 AM, Sebastien ESTIENNE wrote:

> > To provide such a service, you should define:
> >
> > 1) the ability for a dependency to fail
> Yes that's i was asking if this feature exist, it could be implemented  
> like this
>
> depends on apache_bin can fail or a new keyword that would do the same  
> thing named "before"

Using dependencies to setup a start order is probably the wrong thing  
to do. Marco is right about that dependencies in monit is a strong link  
between two or more services. Setting a dependency between A and B in  
monit means that A->B in effect is treated as a union (C).

> > 2) a kind of ordering, or at least, the ability to not startup the
> > subsequent service in the list if the previous did not already  
> > completed
> > to startup _without_ using a dependency
> it could be implemented by keywords like before/after
> Gentoo linux already provide this functionnality (look here:  
> http://www.gentoo.org/doc/en/handbook/handbook-x86.xml? 
> part=2&chap=5#doc_chap4 )
> you can define order with before after
> dependencies need/use and also provide
>
> for example you can say that qmail "provide mta" and "need  net"
> and that nagios "need mta"
>
> so the system knows that he must start qmail before nagios (if you had  
> use the "use" keyword instead of "need" it means that qmail can fail  
> it's okà
>
> "provide" is also because you can say that many service provide the  
> same functionnality, eg: mta -> qmail, postfix, exim

(1) Interesting idea. It sounds like something that monit could benefit  
from. It means that we need to replace dependency in monit with the  
keyword "need" and add the keyword "use" for start order and as a weak  
dependency. (If I got this right?)


> > 3) some tool to easily rearrange the services (a chkconfig-like tool)  
> > 4)
> > the ability tu support different runlevels
> I wrote this tool, it was easy, i just modified the default tool from  
> gentoo (it was just a matter of 5 lines)

Care to share the tool with the list?

> you said that monit is only good in specialized situation, or when  
> customized, it's true, but you can define default and then allow the  
> user to provide custom settings without modifying the default install,  
> using include:
> the default, would only check for pid, and listening port and then the  
> user can overide things or adding things by including his  
> configuration:
> eg:
> /etc/monit.d/system/SERVICE <- contain all default service config
> and each SERVICE contain a line like this at the end: include  
> /etc/monit.d/user/SERVICE
> so when a user want to customized apache for example, he just have to  
> create a file /etc/monit.d/user/apache

Very cool

> I think that monit can remplace the default system, because the onlyt  
> things that the default init system has to do, is stating/stopping  
> system in the right order nothing more
> and i don't see why monit couldn't do this?
> for example djb's daemontools where built to manage services (they  
> manage qmail/djbdns) and monit seems to be a daemontools++. too bad he  
> also missed the ability to define services start order...

If we missed this it doesn't mean that it cannot be changed. I also  
think that you can use monit with success as a replacement for sysinit  
startup scripts, but means to set the start order is needed, (2) In  
addition monit should have the ability to start a process without  
depending on a pid file. (As stated in the first comment to monit here,  
http://freshmeat.net/projects/monit/) I.e. monit needs to listen to the  
SIGCHLD signal for processes it start, so if a child dies monit get a  
signal and can restart the process. I haven't looked at the init nor  
the daemontools code, but I'm pretty sure this is what those programs  
do. The reason we don't do this already is that monit was (initially)  
designed to monitor processes that was started outside of monit's  
control. (To listen for SIGCHLD monit must start the process).

I think as a start we should add (1) and (2) to our TODO list. What do  
the other commiters think?

With regards
--
Jan-Henrik Haukeland