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 instances. Ale -- ------------------------------------------------------------------------------ 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 courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
