Re: starting service order

[Marco Ermini]

<quota chi="Sebastien ESTIENNE">
>
>>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"
</quote>

This would sound cool.


<quota chi="Sebastien ESTIENNE">
>>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
>
</quota>

No, I never used gentoo (that's a fault, actually, since I think I sould
try it...). Just having a quick look at that web page (so don't think I am
actually "judging" or something similar, it's just the first impression of
a Unix sysadmin - and I _can_ change my mind, I'm not that kind of
sensitive :-), it sounds like it's a way to manage system startup too much
complicated for an Unix sysadmin' "average" taste; it seems like it adds
complexity that it's not worth the cause. When I configure an MTA I want
it to work and work the way I want: I don't want a "replacement" MTA to
start if my MUA fails, since I spent time configuring _my_ MTA, the MTA I
_choosed_, with my blacklists, anti-spam etc. etc. - and it's actually a
_cost_ to configure two different software in the same way "just in the
case"...

Finally, I think that your idea would add some level of complexity to
monit, which may be useful, but I don't know if the authors would like -
let's see what they think about that :-)


<quota chi="Sebastien ESTIENNE">
>>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)
> I did it like this:
> in /etc/monitrc i added  "include /etc/monit.d/autostart/*"
> in /etc/monit.d/ i put a file by service (eg: apache postfix mysql)
> and the tool just write or remove a link from /etc/monit.d/ in
> /etc/monit.d/autostart
> so i have the exact same functionnality as a tool like chkconfig
> (i don't know if you use gentoo, but now i add services like this:
> rc-update add apache monit)
</quota>

I didn't know about how gentoo works, but this sounds interesting: adding
and removing a service from monit with a command it could be useful... but
maybe you can just unmonitor it? :-)

Anyway it seems to me this is just a way of using monit: adding or
removing a file from a directory is just a matter of a 5 line script (like
you already said) and this did not require any modification to monit - I
think.


<quota chi="Sebastien ESTIENNE">
> 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
>
> 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...
</quota>

The first thing I usually think is that a program should serve the purpose
it was being created for. The "Unix way" of thinking is: simple tools to
be put together in a simple way. Changing Monit to being more complex to
serve a different purpose for what it was conceived for, sounds to a
"Unix" mind like mine (a little simple and orthodox, I think ;-) like some
kind of "noise" I don't need to listen to ;-)

Anyway you can do it... adding a feature to monit it's not forbidden by
the law ;-) and two of the features you suggested (dependencies which can
fails, and the order of startup) could be useful to the "conventional" way
of using Monit, too (I think).

I think that there is a much more useful option which is missing: the
"startup in progress" option... when a service is long to startup (think
about Java application servers, ecc.), Monit becomes unresponsive if you
ask for a "status".

I think that starting a service should spawn a different thread and
changing the status in "startup in progress" (this would need to be
configurable from the monitrc file). This could also be useful in a
"system startup" situation like you want for gentoo, as it would speed up
the startup of the whole system if you have services which didn't need to
be "dependable" from each others.


Regards.
-- 
Marco Ermini
http://www.markoer.org
Dubium sapientiae initium. (Descartes)
<< This message is for the designated recipient only and may contain
privileged or confidential information. If you have received it in
error, please notify the sender immediately and delete the original.
Any other use of the email by you is prohibited. >>