Thank you for your reply.
> Andrea:
>
> If there is a way to configure Mon to report a service as down after a
> number of failures, then that is my recommendation. Just because a
> service fails a test once doesn't mean that it's down. I could just be
> busy.
You're right, but the strange beaviour is: when service fails (in monitoring
opinion :) the server is not busy. As I reported in another mail, this is
what happens:
2001-06-12 13:27:03.855642500 tcpserver: status: 1/50
2001-06-12 13:27:03.856118500 tcpserver: pid 17372 from 10.10.32.135
2001-06-12 13:27:11.326985500 tcpserver: ok 17372 pop3.frontend.int:ip:10025
:ip::4563
2001-06-12 13:27:11.334100500 tcpserver: end 17372 status 256
2001-06-12 13:27:11.334181500 tcpserver: status: 0/50
As you can see, from 13:27:03 tcpserver spawn at 13:27:11, far away from
timeout for monitoring (5 secs).
A normal session is like:
2001-06-12 13:28:15.451685500 tcpserver: status: 1/50
2001-06-12 13:28:15.452134500 tcpserver: pid 17378 from 10.10.32.135
2001-06-12 13:28:15.452904500 tcpserver: ok 17378 pop3.frontend.int:ip:10025
:ip::4585
2001-06-12 13:28:15.460697500 tcpserver: end 17378 status 0
2001-06-12 13:28:15.460778500 tcpserver: status: 0/50
If you look at status, you'll see that is far away from busy: it's the only
active session! And: why all others services (ie: Apache) never fails?
I thought it may be the Coda FS (qmail/vpopmails mailboxes are running on
Coda): but even apache is running on Coda, and more accessed files are
cached by clients, so I discarded this idea.
Two solutions are: increase timeouts to 10secs (in that case it appears to
respond after 8) or set the alarm after N failures... but why tcpserver is
delaying 8 secs? I mean, if I discover the cause, I'll solve my problem.
Thank you again
---
Cordiali saluti / Best regards
Andrea Cerrito
^^^^^^^^^^^^^^
Net.Admin @ Centro MultiMediale di Terni S.p.A.
P.zzale Bosco 3A
05100 Terni IT
Tel. +39 744 5441330
Fax. +39 744 5441372
