Yea, that code ... I'm sitting on set of changes:
- stop kernel.c randomly discarding sigchilds (oops) - stop the strangeness where signal handlers are installed twice; only the second is needed, the first looks like hangover from pre-event-loop days - get this code correctly working with multiple children and multiple forks + /* + * ??? Super tricky: + * If addconn_child_pid == 0 (i.e. there is no addcon child) + * wait for any child process whose process group ID is equal to that of the calling process. + * Otherwise: wait specifically for the addconn_child_pid. + */ I don't think that was the intent (I suspect you're giving the code too much credit :-). The signal handler is currently set up to fire only once and the code seems to expect it to be from addconn. Now the scary bit - the reason for the fork() is so that PAM can run in a separate process. While my code passes the test suite, that isn't saying much. After the fork(), I know I need to restore the signal table; I'm wondering what else. (technically this is the simplistic fork() implementation, I believe SSH always two processes chatting to each other, and then has one of them forking when pam is needed) Andrew ---------- Forwarded message ---------- From: D. Hugh Redelmeier <[email protected]> Date: 18 October 2017 at 03:13 Subject: [Swan-commit] Changes to ref refs/heads/master To: [email protected] New commits: commit b59e3acd24b5617ee7aa623f46f65f35addb0dab Author: D. Hugh Redelmeier <[email protected]> Date: Wed Oct 18 03:11:15 2017 -0400 pluto: server.c: illuminate childhandler_cb; ditch side-effects from passert arg _______________________________________________ Swan-commit mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-commit
_______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
