[Chilli] chilli_redir hung on reading from unavailable socket

[Liran Tal]

Hey,

On what kind of system is this running?

Makes sense that the file descriptor varies in different runs.
Also, since it's saying resource temporarily unavailable maybe it's reaching
it's limit to create
file descriptors, this is a configuration in the OS and while this is
usually very high I'm not
sure what kind of system you're running so maybe check that first.

Also, maybe you should wait a second, then re-read().
And another option, I'm not familiar with the code (just replying with some
ideas that might help) but is
the socket set to non-blocking mode?


Regards,
Liran.


On Sun, Jun 13, 2010 at 4:00 PM, Wichert Akkerman <wichert at wiggy.net> wrote:

> Almost forgot I extracted a backtrace by attaching gdb to the spinning
> chilli_redir process:
>
> #0  0xb7f1a424 in __kernel_vsyscall ()
> #1  0xb7c8d1e3 in read () from /lib/i686/cmov/libc.so.6
> #2  0xb7dcb257 in ?? () from /usr/lib/i686/cmov/libcrypto.so.0.9.8
> #3  0x0000000c in ?? ()
> #4  0x08e31350 in ?? ()
> #5  0x00000005 in ?? ()
> #6  0xb7e62124 in ?? () from /usr/lib/i686/cmov/libcrypto.so.0.9.8
> #7  0x08dab308 in ?? ()
> #8  0x00000000 in ?? ()
>
>
>
> On 2010-6-13 14:17, Wichert Akkerman wrote:
>
>> r345 worked flawlessly for 4 days, but unfortunately showed the same
>> symptom today:
>>
>> read(12, 0x8e31350, 5) = -1 EAGAIN (Resource temporarily unavailable)
>> read(12, 0x8e31350, 5) = -1 EAGAIN (Resource temporarily unavailable)
>> read(12, 0x8e31350, 5) = -1 EAGAIN (Resource temporarily unavailable)
>> read(12, 0x8e31350, 5) = -1 EAGAIN (Resource temporarily unavailable)
>> read(12, 0x8e31350, 5) = -1 EAGAIN (Resource temporarily unavailable)
>> read(12, 0x8e31350, 5) = -1 EAGAIN (Resource temporarily unavailable)
>> read(12, 0x8e31350, 5) = -1 EAGAIN (Resource temporarily unavailable)
>> read(12, 0x8e31350, 5) = -1 EAGAIN (Resource temporarily unavailable)
>>
>> as you can see the strace is very similar, but has two differences:
>> there is no time(NULL) call in between the read() calls, and this is a
>> different fd (12, while I was seeing 25 before).
>>
>>
>> On 2010-6-8 09:17, David Bird wrote:
>>
>>> Btw, the problem was reproducible (without waiting) by telneting to
>>> https://uamasliasip/ and just hit<enter>. Previously, this would start
>>> the looping on read() as it attempts ssl negotiation.
>>>
>>> On Tue, 2010-06-08 at 09:13 +0200, Wichert Akkerman wrote:
>>>
>>>> On 6/7/10 12:19 , David Bird wrote:
>>>>
>>>>> See revision 345. There was an issue when using chilli_redir and
>>>>> openssl
>>>>> and looping instead of returning during ssl accept. chilli_redir
>>>>> handles
>>>>> UAM connections asynchronously, whereas when you don't compile with
>>>>> --enable-chilliredir connections are handled by a forked process (and
>>>>> hence will block on accept/read/write).
>>>>>
>>>>
>>>> Great! I've deployed r345 last night so I should know within 2-3 days of
>>>> this helped.
>>>>
>>>> Wichert.
>>>> _______________________________________________
>>>> Chilli mailing list
>>>> Chilli at coova.org
>>>> http://lists.coova.org/cgi-bin/mailman/listinfo/chilli
>>>>
>>>
>>>
>>>
>>
>>
>
> --
> Wichert Akkerman <wichert at wiggy.net>   It is simple to make things.
> http://www.wiggy.net/                  It is hard to make things simple.
> _______________________________________________
> Chilli mailing list
> Chilli at coova.org
> http://lists.coova.org/cgi-bin/mailman/listinfo/chilli
>



-- 
-- 
Sincerely, Liran Tal

Founder and CTO
Linux and Open Source
Enginx - http://enginx.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.coova.org/pipermail/chilli/attachments/20100613/3dfca3f7/attachment.htm>