Michael Carmack writes:
Oddly enough, the act of running an strace on the root perlfilter process seems to fix the problem. If I run strace on the root perlfilter _before_ trying to stop courierfilter, I never see any looping when I shut it down. And if I run strace on the root perlfilter process _after_ trying to stop courierfilter, while all of the rest of the perlfilter processes are respawning, then the respawning immediately stops and the courierfitler stops.
That sounds almost like when perlfilter's root parent process gets a signal, it doesn't really "get it", but as soon as it forks off a child process, the child process realizes that it just got signal and dies, then the parent just respawns it. And when you try to strace the root parent process, it realizes that it got a signal, and dies.
You said you've put together a custom kernel. Try a different major kernel version first, to see if you can reproduce the behavior.
The stop command first sends a SIGTERM, and if the lock file isn't released, that's followed by a SIGKILL after ten seconds. Presuming that your stop command never terminates, it's going to be sending SIGKILLs every ten seconds. strace the stop process, and see for yourself that it's sending SIGKILLs every ten seconds, to the same pid.
pgpTjkT5otXfH.pgp
Description: PGP signature
------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
_______________________________________________ courier-users mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
