ProFTPD Server Software

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

tj@... changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |minor





------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

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





------- Additional Comments From tj@...  2003-07-31 21:06 -------
Patch committed to CVS.  Can you confirm that it addressed your issue?



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

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





------- Additional Comments From ikeda@...  2003-07-31 22:53 -------
I think it unrelated that pr_signals_handle() does not exist. 
Because, SIGNAL reception read() having been interrupted, EINTR is detected.
And when EAGAIN is detected, SIGNAL is not received.


------------------------------------------
pstack
------------------------------------------
767:    /usr/local/sbin/proftpd
 ff19e574 _read    (b2470, bc160, 2000, 2a274, 79800, 0) + c
 0002b0cc pr_netio_read (0, bc160, 2000, 1, 10, 44) + 19c
 0002d944 pr_data_xfer (0, 2000, 586, 0, 0, 5acd2) + 168
 000425c8 xfer_stor (b1e28, 7a800, 7aa90, 60c00, 77000, ffbef558) + 690
 0002e248 call_module_cmd (77584, 41f38, b1e28, 0, 45000000, 45000000) + 28
 000171e4 _dispatch (b1e28, 2, 5ac00, b1e78, 1, ff1a7530) + 2a4
 000174dc pr_cmd_dispatch (b1e28, 0, ffbef6b8, 7efefeff, 81010100, ff00) + 150
 00017af4 cmd_loop (75400, 5b000, ff327c80, 2c2d, 5b800, 187a4) + 3b0
 00018cb8 fork_server (aa630, ffbefb6c, 7d950, aa200, 2218c, 19190) + a54
 00019370 daemon_loop (75400, 75000, 0, ffbefc30, 75000, 75400) + 48c
 0001ba54 standalone_main (1, 75400, ea61, a3a, 5b800, 1bed4) + 354
 0001c284 main     (0, ffbefe1c, ffbefe24, 5b000, 5b000, 5bda8) + 7c0
 000163f4 _start   (0, 0, 0, 0, 0, 0) + 5c

------------------------------------------
truss
------------------------------------------
read(14, 0x000B9918, 8192)                      Err#11 EAGAIN
read(14, 0x000B9918, 8192)                      Err#11 EAGAIN
read(14, 0x000B9918, 8192)                      Err#11 EAGAIN
read(14, 0x000B9918, 8192)                      Err#11 EAGAIN
... infinite loop ...




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

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





------- Additional Comments From tj@...  2003-08-01 01:26 -------
With the pr_signals_handle() in place, the while() loop continues -- and the
first thing that happens at the top of the loop would be the handling of
signals.  While this would not handle the EAGAIN case per se, it would prevent
the endless loop, for the timeout eventually is enforced via delivery of a
signal.  Without the pr_signals_handle() call, that timeout signal will not be
handled, the loop will become endless.  At least in this case now, the loop will
eventually be terminated by a timeout.

Also, what does your config.h look like?  Is the #ifdef condition added by
Bug#1964 happening on your box?



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

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





------- Additional Comments From tj@...  2003-08-01 01:37 -------
As in Bug#1964, is this read() occurring on a file on an NFS filesystem?  If so,
what NFS version and mount options are being used?



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

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





------- Additional Comments From ikeda@...  2003-08-01 05:04 -------
Thank you very much.

I understand that, pr_signals_handle() is handling timeout signal.

I'll compile proftpd with patch and test in next week.
But this trouble is rarely. 
It may take long time, in order to check what the trouble solved by application 
of a patch.

I use NFS server "EMC Celerra" and NFS client "Sun V100"(solaris8).
NFS version is 3.
Mount option is "soft,bg".
No errors found in NFS logs.

But, this read() is in pr_netio_read().
I think that, pr_netio_read() is reading fron socket, and pr_fsio_read() is 
reading fron file system, isn't it?



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

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





------- Additional Comments From tj@...  2003-08-01 18:14 -------
Hrm.  You're thinking that the same ioctl(RPROTDIS) call may be needed on the
socket as well, perhaps?



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

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





------- Additional Comments From ikeda@...  2003-08-04 00:49 -------
I do not specifically think to there.
I think that, this probrem is unrelated to NFS.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

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





------- Additional Comments From ikeda@...  2003-08-06 00:54 -------
A patched proftpd into EAGAIN loop.
The loop was ended in 1 hour.

The situation became better than before.

But, The rate of CPU usage (system + user) in the meantime is 100%.
It is not good.

I think that, Since EAGAIN is received Returning to read() immediately is a 
problem.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

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





------- Additional Comments From tj@...  2003-08-06 01:21 -------
You should always have RLimits in place, such as RLimitCPU.

  htttp://www.castaglia.org/proftpd/doc/contrib/ProFTPD-mini-HOWTO-BCP.html



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

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





------- Additional Comments From ikeda@...  2003-08-06 01:47 -------
In this case, RLimits cannot be used.

Because, The cause that load is applied to CPU It is clear that it is loop.
Only 1 looping process use almost all cpu time.

If restriction is applied in RLimits, access of [ after loop occurs ] will 
become impossible and can not stop looping process.




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

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





------- Additional Comments From tj@...  2003-08-06 01:51 -------
No.  That's not how RLimitCPU works.  You can do:

  RLimitCPU session 60

or something similar.  It's meant to stop session processes who use more than
number of seconds of CPU time, as would happen when your EAGAIN loop occurs.

So I don't understand why you say RLimitCPU cannot be used.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

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





------- Additional Comments From ikeda@...  2003-08-06 02:01 -------
Sorry, I mistook with another option -- MaxLoad --.
I try to use RLimits.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

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





------- Additional Comments From ikeda@...  2003-08-11 01:29 -------
I wrote "RLimitCPU session 60" in proftpd.conf.

The arrangement can shorten time of an EAGAIN loop.
However, it cannot stop generating of an EAGAIN loop.

I thought that it was not cool.

In parallel, I investigated about the cause which EAGAIN generates.
I found a bug of solaris in sunsolve.

   http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fsalert%
2F50981&zone_32=TCP_CO_MIN

I will set "ndd -set /dev/tcp tcp_co_min 1500" and test again.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

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





------- Additional Comments From tj@...  2003-08-11 01:34 -------
I never said that using an RLimit would prevent the EAGAIN.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

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





------- Additional Comments From ikeda@...  2003-08-11 01:51 -------
Of course, that understands.

I recognize that, Since a thing with the normal EAGAIN or abnormal thing could 
not be judged by the program, you recommended judging in CPU time.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

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





------- Additional Comments From ikeda@...  2003-08-18 04:07 -------
I set solaris workaround as the server.
The EAGAIN loop is not generated for one week after that.

I think that the trouble was resolved.
The cause is not a bug of proftpd.
It is the bug of solaris.

If a trouble recurs, I will report again.

Thank you.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

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





------- Additional Comments From tj@...  2003-08-18 13:27 -------
What was the workaround you did from the Solaris side?



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

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





------- Additional Comments From ikeda@...  2003-08-18 22:43 -------
The workaround is written in "4. Relief/Workaround" section of this URL.

http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fsalert/50981&zone_32=TCP_CO_MIN




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

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





------- Additional Comments From tj@...  2003-08-30 16:00 -------
Created an attachment (id=1851)
 --> (http://bugs.proftpd.org/attachment.cgi?id=1851&action=view)
Patches handling of EAGAIN in pr_netio_read()

Perhaps this simple patch might correct the issue in a better way, rather than
tuning the TCP stack on Solaris?



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

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





------- Additional Comments From ikeda@...  2003-08-30 16:31 -------
I think so too.
I will test this patch without solsris tuning.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

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





------- Additional Comments From ikeda@...  2003-09-09 07:32 -------
I tested the patch.
After applying the patch, I have not found the problem.




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.