Moin!
After I read the discussion about the Timeout issue earlier I thought
again about the sendmail code. And I don't like how it is
right... cuz mail which have trouble being delivered simply get lost
and all you get is a syslog/logfile entry. IMO, that doesn't really
fit to monit concept robustness.
Why not a simple(!) queue based sendmail thread... Whenever a mail
has to be send you append it to a chained list and give it time()
ticket and a retry counter. The event code isn't blocked anyhow, as
long as no access is being done to the mail queue.
The implementation can use pthread condition variables for waiting and
signalling. Whenever the sendmail thread has worked itself through
the whole queue it sets itself asleep with pthread_cond_timedwait for
a period of time (like daemontime). In case a mail is being put in
the mail queue. The thread is woken up by pthread_cond_signal and the
thread tries to send out all the mails which have been appended to the
queue. If the condition times out, the thread works itself through
the whole queue from the beginning.
Pursuing this way no mail monit has tried to send out is getting lost
(as long monit is not shutdown). Higher network timeouts won't block
monits code.
I have played around little bit with condition variable and I think
it's a with feasible way to implement it.
So, what do you think???