Re: [Ipsec-tools-devel] ipsec-tools repository

[Rainer W. <rwe...@mo...>]

Reinoud Koornstra <rei...@gm...> writes:

[...]

> Last Rainer wrote a patch to handle signals a little different that
> worked out in our case.

Since there seems to be some confusion around this: Minus the fact that
I can't test changes to racoon post 0.7.3 without replacing a 'working'
racoon on some virtualized VPN server, IOW, without demolishing my
regular development/ testing environment, as the different version would
have none of all the iOS, Windows and Android interoperability
improvements, other bug fixes and general improvements in 'our' version,
there's nothing which (sort-of accidentally) 'worked out' in this
change: That's a part of how the daemon should have handled signals to
begin with[*] instead of the strange construction employing the static
sigreq array, the handler setting values corresponding to received
signals and the "call me lost wakeup" select call (it's actually the
same method also employed by the proprietary racoon fork of my employer,
except that that uses epoll_pwait instead of pselect as it's not
supposed to support anything but Linux).

[*] To be fair, pselect is POSIX.1-2001 and Linux didn't support pselect
    at all until glibc 2.1 and an actually working version became
    only available with Linux 2.6.16. But workarounds which don't loose
    signals (at least for some time) exist. The usual one would be to
    use a signal handler writing received signals to a pipe and include
    the read end of the pipe in the set of fds select 'listens' on, thus
    handling received signals from the main loop without running the
    risk of interrupting signal-unsafe functions and then running code
    which is itself not async signal safe.