Restarting ocserv doesn't clean up all workers
Nikos Mavrogiannopoulos
nmav at gnutls.org
Sun Oct 5 13:34:40 PDT 2014
On Mon, 2014-10-06 at 00:43 +0800, Niels Peen wrote:
> > On 05 Oct 2014, at 03:17, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> >
> > So, if I understand correctly, there was a user connection at some
> > point, which go stuck?
>
> Yes. As far as I can tell these are worker processes that handle a user’s connection. At some point the user disconnects (or loses signal - many of the disconnects are unintentional) and the worker doesn’t get killed. Looking at today’s log It happens to about 1 in 400 workers.
>
> > There are numerous places where this could occur. Would it be possible
> > to run:
> > $ gdb /usr/sbin/ocserv 21306
> > $ bt full
> Hope this helps:
It does, thank you. It seems we are in the case:
'Under Linux, select() may report a socket file descriptor as "ready for
reading", while nevertheless a subsequent read blocks. This
could for example happen when data has arrived but upon examination
has wrong checksum and is discarded. There may be other
circumstances in which a file descriptor is spuriously reported as
ready. Thus it may be safer to use O_NONBLOCK on sockets that should
not block.'
So if the client disconnected and a packet with wrong checksum is
received, that block occurs, as ocserv depended on select() to check for
data. I've modified ocserv to use non-blocking sockets in master to
avoid that. It seems to work fine in my setup, but I'd like to have more
testing prior to a release.
regards,
Nikos
More information about the openconnect-devel
mailing list