Re: starting service order

[Christian Hopp]

On Tue, 6 Jul 2004, Jan-Henrik Haukeland wrote:

> 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?

(1) I think we really need to dive deep into graph theory then for a
relialble implementation.  (definitely not my field of research) (-:

(2) Interesting but too dangerous.  Breaks the concept of having a
validation loop.  Then we would have signal based tests and a validation
loop.  The signal based code might break with the multitreaded code.  And
it breaks with the "unix" idea one small tool for each task.  I think init
is there where its supposed to be.  I think we would not get past a proof
of concept and wouldn't achieve anything a user would adept.  Just my two
cents.

Christian

-- 
Christian Hopp                                email: address@hidden
Institut für Elektrische Informationstechnik             fon: +49-5323-72-2113
TU Clausthal, Leibnizstr. 28, 38678 Clausthal-Zellerf.   fax: +49-5323-72-3197
                             pgpkey: https://www.iei.tu-clausthal.de/pgp-keys/