On Fri, 23 Sep 2016, [email protected] wrote:
...
> The iked config test in /etc/rc.d/iked hangs fairly reliably. I've
> ktraced it and it looks like this when hanging, stopping at the
> wait4:
>
> 91211 iked CALL write(2,0x7b37a13ec73,0x11)
> 91211 iked GIO fd 2 wrote 17 bytes
> "configuration OK
> "
> 91211 iked RET write 17/0x11
> 91211 iked CALL kbind(0x7f7ffffce4f8,24,0x2e9d25833eef97c0)
> 91211 iked RET kbind 0
> 91211 iked CALL kill(-91211,SIGTERM)
> 91211 iked RET kill -1 errno 3 No such process
> 91211 iked CALL kill(-84806,SIGTERM)
> 91211 iked RET kill -1 errno 3 No such process
...
> The kill pids are all valid pids (one is the process itself), and
> earlier in the ktrace output they were fork results:
Not quite: the absolute value of the kill argument is a valid pid, but
passing the negation of it changes the meaning:
For compatibility with System V, if the process number is negative but
not -1, the signal is sent to all processes whose process group ID is
equal to the absolute value of the process number. This is a variant of
killpg(3).
By default, a process inherits the process group of its parent, so unless
those process are calling one of setpgrp()/setpgid()/setsid(), then there
*isn't* a matching process group and the error return is correct, which
would mean the calls to kill() should be changed to not negate the
argument.
(And how iked shuts down should probably be simplified; I believe the
modern preference is to close the imsg sockets or pipes between process
and let them take that as the indication to exit cleanly.)
Philip Guenther
