Iâve done this, and it may well be epoll-specific; the test has now run
over twice as long as the longest it has ever required to produce the
deadlock. With this sort of bug no amount of waiting would make me sure,
but it seems likely. Iâll leave it running.
epoll(7) specifically mentions the possibility of epoll_wait hanging even
though there is outstanding unread data on a socket, when using
edge-triggered operation, and I notice in daemon.c that you switch to
edge-triggered mode in the event that the client closes the connection (at
least thatâs what the comment suggests):
/* Don't keep reporting the hangup
*/
if ( SLAP_SOCK_IS_ACTIVE( tid, fd )) {
SLAP_EPOLL_SOCK_SET( tid, fd, EPOLLET );
}
Perhaps related?