Re: stuff to work on

[Martin Pala]

Rory Toma wrote:
> I'm looking for the things that I should be working on in monit, and
> here's my list (no timetable yet)
>
> 1) /proc support for mac os X
> 2) Get current FreeBSD port working
> 3) add snmp support
>
> anything else that anyone can think of?

Good objective :)

My priority list:

1.) SMTP update (message queue + state machine)
2.) "up" event (ability to notice the bidirectional state transtition)

I though about about both points, but i preffer the work on other 
project temporarily, so i don't plan to work on it some time.



To the message queue and smtp state machine design, i though about 
following implementation:

1.) refactor the structures:

--8<--
 /** Defines a message */
 typedef struct mymail {
   char *to;         /**< Mail address for alert notification */
   char *from;       /**< The mail from address */
   char *subject;    /**< The mail subject */
   char **message;   /**< The mail message */
} *Mail_T;


/** Defines a mailinglist */
typedef struct mymaillist {
  Mail_T  entry;   /**< Message definition */
  unsigned events; /**< Events for which this
                    **  mail object should be
                    **  sent */
 /** For internal use */
 struct mymaillist *next;  /**< next message definition in chain */
} *MailList_T;


/** Defines a mail queue */
typedef struct mymailqueue {
  Mail_T entry;     /**< Message definition */
  time_t timestamp; /**< Message creation timestamp */
  int    counter;   /**< Delivery attempts counter */
  short  failover;  /**< Try to deliver via
                     **  backup server in
                     **  the same session */
  /** For internal use */
  struct mymailqueue *prev;    /**< previous message in chain */
  struct mymailqueue *next;    /**< next message in chain */
} *MailQueue_T;
--8<--

The object Mail_T is common message part and it is inherited by 
MailList_T and MailQueue_T. The variable "char **message" allows to add 
more message parts and replaces present "char *message"+"char 
*opt_message" variables => i think it simplifies the code of message 
handlers.

The MailList_T serves for parser to store alert contacts here. It is 
oneway list of alert contacts.

The MailQueue_T contains bidirectional list of messages added to the queue.


2.) addition of the message to the queue:
Event handler (in alert.c) manages the alerts as usual except the 
message delivery part. In the case that the mail should be send, it adds 
the mail message to the end of the mail queue and sets the creation 
timestamp to the current time. MailQueue list is either backed by memory 
or mmaped file. The file could be better because it will be easier to 
save the queue on monit's exit. At the end of queue extension will the 
event handler call sendmail() or it can run optionaly in standalone thread.


3.) message delivery:
Sendmail will go through the queue. It can skip messages which are 
remaining in the queue based on their delivery counter - the attempts to 
deliver the message can exponentialy slow down (thus the delivery 
attempts will be driven each cycle on per-message basis). In the case 
that the timestamp is older than given limit (for example four days), 
the message will be discarted from the queue.


4.) state machine:
Each stage of the smtp session will be protected - in the case that the 
message delivery will fail for some reason with non-fatal error on the 
first smtp server, it will be tried in the same cycle on the next server 
(in the case that more servers are defined). In the case that fatal 
error is returned, this message ends this cycle. Monit will send in the 
one smtp session as much messages as possible. In the case that the 
message was successfully delivered, it is taken out of the list (free 
the message and relink "prev" and "next" pointers).


5.) on monit exit, monit will save the queue


Note: It could be possible to use common Mail_T pointers in MailList_T 
and MailQueue_T lists to save memory (each message needs to be stored 
only once). However on monit exit or configuration reload the list must 
be "deeply" copied to save the correct state.


What do you think about it?


Martin