It should be fairly easy to change start to also become
"synchronously". Synchronously in this context means that monit will
wait in the same thread which started the process and poll-check for
a pidfile to be created. This is how synchronously stop is handled
today.
The rationale for not waiting for a process to actually start before
moving on to the next is, I believe, that we thought if was best to
start as soon as possible. Waiting and poll-check for a pidfile could
take time in case of failure to start, before monit timed out and
moved on to start the next process. With many services to check,
there would be a potential for monit's poll cycle to take "a long
time" in case of problems.
Today the solution is to start as soon as possible and instead spin
of one wait-thread per started process and check if the process did
start and if not, report an error.
Of course, this solution does not play too well with a dependency
chain, particularly if you expect A to come up before monit starts B
etc. Now monit just start A and B more or less simultaneously.
1) Maybe start time is not the crucial point here, but rather
"correctness", that is, monit should wait for A to come up before
starting B and so on?
2) Apropos correctness. This brings up another question, if you have
a dependency chain, say, C->B->A, today if monit should fail to start
A, it still goes on and try to start B and C. If A failed to start,
should monit instead abort the chain and not try to start B and C
regardless? I'm not sure.
I do not know if changing start to also become synchronously will
have unwanted side effects, I don't think so? Martin?
In case we decide to do this change, do you have a good test case and
would be willing to test?
What do the other comitters think? Should we change 1) and 2) above?
Best regards
--
Jan-Henrik Haukeland
On 5. sep. 2007, at 15.42, Stanisław Trytek wrote:
From our experience monit works properly when closing services. It
closes services in accordance with declared dependieces and
services wait for another.
Your problem may be caused by stdout, it can happen.
The problem is with starting services. In spite of dependencies
monit starts them at once, and it causes mess in some environments.
It would be great if both starting and stoping work synchronusly.
We made some attempts to overcome this issue.
Stanislaw Trytek
--
_________________________________________
PRZEMYSŁOWY INSTYTUT TELEKOMUNIKACJI
TELECOMMUNICATIONS RESEARCH INSTITUTE
ul. Poligonowa 30, 04-051 Warszawa, Poland
tel: +48 (22) 48 65 232
fax: +48 (22) 48 65 494
e-mail: [EMAIL PROTECTED]
On Tue, 04 Sep 2007 03:21:13 +0200, Jason L. Buberel
<[EMAIL PROTECTED]> wrote:
My configuration is using monit 4.10-beta-1 on RHEL3. I have
configured a dependency chain for squid and apache:
squid ---depends-on--> apache
Squid in particular can take a while to shutdown. In fact the
official squid init.d script contains a section that looks like this:
timeout=0
while : ; do
[ -f /opt/squid/var/logs/squid.pid ] || break
if [ $timeout -ge $SQUID_SHUTDOWN_TIMEOUT ]; then
echo
return 1
fi
sleep 2 && echo -n "."
timeout=$((timeout+2))
done
When I issue a 'monit restart apache' command, I see the following
in stdout:
'squid' stop: /etc/init.d/squid.local
Stopping squid: 'apache' stop: /usr/local/bin/stop-apache.bash
. [ OK ]
Which tells me that the 'apache stop' is being executed before the
'squid stop' has actually completed. If the commands were executed
serially, the output would have been:
'squid' stop: /etc/init.d/squid.local
Stopping squid: ...... [ OK ]
'apache' stop: /usr/local/bin/stop-apache.bash
This seems similar to what is described:
http://lists.nongnu.org/archive/html/monit-general/2007-04/
msg00007.html
Would it be possible to add a 'synchronous' flag to the start/stop
parameters to force monit to wait for the script to exit fully:
start synchronous "/etc/init.d/service start"
stop synchronous "/etc/init.d/service stop"
Or something to that effect?
-jason
--
To unsubscribe:
http://lists.nongnu.org/mailman/listinfo/monit-general
--
To unsubscribe:
http://lists.nongnu.org/mailman/listinfo/monit-general
--
To unsubscribe:
http://lists.nongnu.org/mailman/listinfo/monit-general