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.
6 messages in net.sourceforge.lists.courier-usersRe: [courier-users] Courier perlfilte...
.txt
