[ProFTPD-committers] [Bug 3639] Avoid spinning proftpd process if read(2) returns EAGAIN

[b***@horde.net]

http://bugs.proftpd.org/show_bug.cgi?id=3639

TJ Saunders <***@castaglia.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Keywords| |Backport
Status|NEW |ASSIGNED
CC| |***@ordal.com,
| |***@secure-computing.net
| |, ***@debian.org,
| |***@maytech.net,
| |***@city-fan.org,
| |***@io.com

--- Comment #1 from TJ Saunders <***@castaglia.org> 2011-04-05 21:50:48 EDT ---
A proftpd user recently provided the following strace/lsof info for a spinning
proftpd process:

% strace -p 32645
Process 32645 attached - interrupt to quit
read(14, 0x1d8480c4, 1139) = -1 EAGAIN (Resource temporarily
unavailable)
read(14, 0x1d8480c4, 1139) = -1 EAGAIN (Resource temporarily
unavailable)
read(14, 0x1d8480c4, 1139) = -1 EAGAIN (Resource temporarily
unavailable)
read(14, 0x1d8480c4, 1139) = -1 EAGAIN (Resource temporarily
unavailable)
read(14, 0x1d8480c4, 1139) = -1 EAGAIN (Resource temporarily
unavailable)
read(14, 0x1d8480c4, 1139) = -1 EAGAIN (Resource temporarily
unavailable)
read(14, 0x1d8480c4, 1139) = -1 EAGAIN (Resource temporarily
unavailable)
read(14, 0x1d8480c4, 1139) = -1 EAGAIN (Resource temporarily
unavailable)
read(14, 0x1d8480c4, 1139) = -1 EAGAIN (Resource temporarily
unavailable)
read(14, 0x1d8480c4, 1139) = -1 EAGAIN (Resource temporarily
unavailable)
read(14, 0x1d8480c4, 1139) = -1 EAGAIN (Resource temporarily
unavailable)
read(14, 0x1d8480c4, 1139) = -1 EAGAIN (Resource temporarily
unavailable)
Process 32645 detached

% lsof -p 32645
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
<...trimmed for anonymity...>
proftpd 32645 ftp 14u IPv4 1349183980 TCP
origin.x.x.x.x:60168->xxxxx.example.com:pptp (ESTABLISHED)
proftpd 32645 ftp 15u IPv4 1349183980 TCP
origin.1.2.3.4:60168->xxxxx.example.com:pptp (ESTABLISHED)

The strace/lsof info shows me that the fd in question (14) is a socket.
Unfortunately I can't tell from that info whether it's the control or the data
connection. But read(2) only returns EAGAIN for a socket that's been placed in
nonblocking mode, and proftpd only sets sockets in nonblocking mode for data
connections.

[b***@horde.net]

http://bugs.proftpd.org/show_bug.cgi?id=3639

--- Comment #2 from TJ Saunders <***@castaglia.org> 2011-04-05 22:01:17 EDT ---
Created attachment 3603
--> http://bugs.proftpd.org/attachment.cgi?id=3603
Fixes bug (hopefully)

This patch should avoid the worst of the CPU consumption by adding a (by
default) 200 millsecond delay between each select(2)/read(2) attempt.

[b***@horde.net]

http://bugs.proftpd.org/show_bug.cgi?id=3639

John P. Speno <***@isc.upenn.edu> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@isc.upenn.edu

--- Comment #3 from John P. Speno <***@isc.upenn.edu> 2011-04-06 09:33:40 EDT ---
Thanks for the patch. I wonder if there's anyway to have proftpd exit at some
point, otherwise I suspect we'll end up with a process that stays alive albeit
in less CPU intensive way. As it stands now, it's easy to find these hung
connections because they use up 100% of the CPU. :)

[b***@horde.net]

http://bugs.proftpd.org/show_bug.cgi?id=3639

--- Comment #4 from TJ Saunders <***@castaglia.org> 2011-04-06 13:11:54 EDT ---
Ideally a TimeoutIdle would eventually kick in and terminate these sessions.
The tight CPU loop meant that such timers weren't having a chance to do their
job. I'm hoping that with this patch, a TimeoutIdle timer will have a chance
to terminate such processes.

[b***@horde.net]

http://bugs.proftpd.org/show_bug.cgi?id=3639

TJ Saunders <***@castaglia.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED

--- Comment #5 from TJ Saunders <***@castaglia.org> 2011-04-06 13:17:33 EDT ---
Patch committed to CVS, and backported to 1.3.3.