Jeff Potter writes:
daemon 32271 0.0 0.0 3832 328 ? S 17:35 0:00 /usr/lib/courier/sbin/courierfilter start daemon 32273 0.0 0.0 3800 512 ? S 17:35 0:00 /usr/sbin/courierlogger courierfilter daemon 32274 0.0 0.0 183444 9188 ? S 17:35 0:00 /usr/bin/python /etc/courier/filters/active/pythonfilterI have to kill -9 the courierfilter process, and then restart courier and stuff flushes out fine.What am I missing? I would think that “service courier stop” should definitely nuke any process that it started up, but I know there’s a boundary between filters and courier.
You're not really missing anything. It's really the filter's responsibility to wind down its business, once it gets the signal to do so.
Currently, the shutdown code just gives up, after a timeout, in this manner. I do agree that an attempt should be made to kill all processes, after a reasonable timeout, so it's something that I need to look at.
pgp2eAP94eghV.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 courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
