monit-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Sendmail code...


From: Jan-Henrik Haukeland
Subject: Re: Sendmail code...
Date: Mon, 13 Oct 2003 02:02:02 +0200
User-agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Reasonable Discussion, linux)

Christian Hopp <address@hidden> writes:

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

Agree, it's not an ideal situation

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

That certainly is one way to do it, implementing a queue using threads
and semaphores is pretty standard and used to implement stuff like
piplines or a filter queues. In our case I think we can get away with
an even simpler implementation; we queue mail in a list or in a table
but instead of using a thread to poll the mail queue we can simply do
this in the main loop in monitor.c right before monit goes to sleep:

    for(;;) {
      validate();
 ->   CHECK_MAIL();      
      sleep(Run.polltime);
      ...
    }

Using one less thread means less complications in the program and
since the end result is the same I think I would like to choose this
solution.

Another equally important thing to do is to rewrite the sendmail SMTP
protocol "implementation" to really handle error situations from the
server and other status codes. For instance now, if one mail address
was written wrong the whole mail list is not sent. Not nice..


> Just a question does the siglongjmp interfere with the sleep call in
> the code? 

No, jumping on the stack should not affect this. Besides if sendmail
has control and does a jump, monit is already awake.

>  We might want to replace sleep expressions in the code by...
>
> #define mysleep(i,j)  {struct timeval tv={i,j}; \
>                        select(1,NULL,NULL,NULL,&tv);}

The only time you would do this, is if there is a need to sleep with
nano-seconds precision. I don't think this is necessary.

> I am on vacation starting Sunday for one week... (-:  FINALLY!!!

Have a nice one!

-- 
Jan-Henrik Haukeland




reply via email to

[Prev in Thread] Current Thread [Next in Thread]