How to detect a client-closed connection during a write from our LDAP server?

Stefan Metzmacher metze at
Fri Sep 30 12:00:28 UTC 2022

Am 30.09.22 um 13:31 schrieb ronnie sahlberg via samba-technical:
> On Fri, 30 Sept 2022 at 21:12, Isaac Boukris via samba-technical
> <samba-technical at> wrote:
>> On Fri, 2022-09-30 at 14:26 +1300, Andrew Bartlett via samba-technical
>> wrote:
>>> I've been trying to chase down the CPU spins reported by our users in
>>> the writev() codepath from our LDAP server.
>>> A private mail the the strace output shows the sockets are in
>>> CLOSE_WAIT state, returning EAGAIN over and over (after a call to
>>> epoll() each time).  That alone would be enough to keep things
>>> spinning.
>>> But they are being shut down, however our LDAP server won't be
>>> triggering a read any time soon, it is waiting to flush the response
>>> out.
>> Why wouldn't it? I mean why does the read waits for the write? if epoll
>> says so then we should read, then we may detect that the client closed
>> it end and may decide to give up the writes.
>> Technically, I think there is no problem to write to a socket after the
>> peer sent us FIN,
> I think possibly the problem is that IF the tcp tx buffer is full, you
> might get -EAGAIN instead of a better error
> if the socket is only half-closed.

The question is why does epoll report EPOLLOUT in that case.
If we don't get that and get EPOLLERR|EPOLLHUP we should
disable reporting unless TEVENT_FD_READ is requested.

See epoll_event_loop() and epoll_handle_hup_or_err().


More information about the samba-technical mailing list