Gordon Messmer writes:

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?

Yes, that was a misnomer. filterctl enables or disables individual filters; and courierfilter is the one that starts and stops all enabled filters.

Attachment: pgpQLl6mAYTm6.pgp
Description: PGP signature

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