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

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.

For that matter, I'm not sure I understand the original question.  It said:
"""After start, pythonfilter is not started — 'filterctl start 
pythonfilter' fails to bring it up with this:
   filterctl start pythonfilter
   ln: creating symbolic link `/etc/courier/filters/active/pythonfilter' 
to `/usr/lib/courier/libexec/filters/pythonfilter': File exists"""

Why is filterctl involved in "service courier restart" at all?  As far 
as I can tell, courier's sysvinit script doesn't invoke filterctl and 
neither does courierfilter.  What am I missing?

Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
courier-users mailing list
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Reply via email to