On Sun 11/Jan/2015 22:36:59 +0100 Gordon Messmer wrote: 
> On 01/09/2015 08:18 AM, Alessandro Vesely wrote:
>> To kill by pid is going to be difficult for forked filters.  I issue a call
>> kill(0, SIGTERM) when the pipe is closed, but I had previously called 
>> setsid().
> I'll note that the man page for filterctl says:
> "When its standard input is closed the mail filter should stop accepting 
> new connections and wait for any existing connections to be closed, 
> prior to exiting."

Issuing that signal after a short sleep is a sort of tensely waiting.  It
should be enough to hurry up a process that seems to be frozen.

SIGTERM is not enough to definitely kill a runaway filter, but issuing SIGKILL
to its process group would kill the issuing process too.  Since courierfilter
keeps track of each filter's pid, it has a better opportunity to supervise
naughty filters.

> I'm not sure, off the top of my head, why it would be a problem for a 
> filter to continue waiting after the timeout.

One has to be able to tear down the MTA in a reasonable time.  The need to run
killall introduces superfluous coupling between those scripts and installed
filters; for example, it may prevent users from running multiple Courier 


New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
vanity: www.gigenet.com
courier-users mailing list
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Reply via email to