New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

high cpu usage when waiting for data on the destination socket [rt.cpan.org #78920] #228

Open
oalders opened this Issue Mar 31, 2017 · 0 comments

Comments

Projects
None yet
1 participant
@oalders
Member

oalders commented Mar 31, 2017

Migrated from rt.cpan.org#78920 (status was 'open')

Requestors:

From aardbeiplantje@gmail.com on 2012-08-12 11:15:03:

Information:
   libwww-perl-6.04
   perl v5.12.2 on x86_64-linux-gnu-thread-multi 
   Linux wihiie 3.2.0-2-amd64 #1 SMP Sun Mar 4 22:48:17 UTC 2012 x86_64 
GNU/Linux

When using LWP::UserAgent to connect to a http(s) webserver, the cpu 
usage goes to 100% (per core fcourse) when waiting for data on that 
socket. It's in fact an infinite loop that only quits when the socket 
has an error.

Sample script:

  use strict; use warnings;

  use LWP::UserAgent;

  my $u = LWP::UserAgent->new(
      ssl_opts => {verify_hostname => 0},
  );
  $u->get("https://127.0.0.1:1443/BIGFILE", ':content_cb' => sub {});


This can be checked with strace, it loops only this:
    
     read(3, 0x13c5ff3, 5) = -1 EAGAIN (Resource temporarily 
unavailable)

This is easily testable by using socat and use it as a TCP proxy (event 
for HTTPS/SSL). One starts a socat and background it while a sample 
script is downloading data. This is of course not a real world situation  
as normally, networking is ok these days. The problem is that sometimes 
networking isnt' great and, morover, when the data doesn't come in *fast 
enough* it also consumes too much cpu cycles. Also, a loop like that 
makes that the timeout parameters are impossible to implement and 
enforce.

I've found multiple of those infinite like loops:
   IO::Socket::SSL has one in readline() (even multiple copy-pasted 
ones)
   Net::HTTP has one which does a select+timeout infinite loop while 
waiting for http response headers on a persistent chunked connection.

This particular one is in LWP::Protocol::http:

409       READ:
410     {
411         $n = $socket->read_entity_body($buf, $size);
412             unless (defined $n) {
413                 redo READ if $!{EINTR} || $!{EAGAIN};
414                 die "read failed: $!";
415             }
416         redo READ if $n == -1;
417     }


Net::HTTP::Methods' read_entity_body() does a nonblocking read and here 
it's unchecked with select().

I must admit that this might be difficult to fix in LWP::UserAgent as 
this module isn't probably ment to do stuff like that. Probably because 
it's next to impossible to have an eventloop like AnyEvent in 
LWP::UserAgent. With AnyEvent::HTTP this is next to perfect - however, 
that lacks a few other things compared to LWP::UserAgent.

It is possible to have at least all read/write's banked with a decent 
select() with a correct bitmask: the fd is known there. Even adding the 
timeout var is perfectly possible. Same for Net::HTTP's select+timeout 
call.
   

  

From victor@vsespb.ru on 2013-12-10 22:08:13:

Can't reproduce.

strace shows

read(3, "\32&Z\323L\201|)>`J\34\2\243\251\35\334\373\226>Z\357\307\250\22p\v)Ux'x"..., 4096) = 4096
select(8, [3], NULL, NULL, {180, 0})    = 1 (in [3], left {179, 999999})
read(3, "\"\207%(\227\1\247\377\0009`\0264\374\211\243\232\257G\\8\240\223DyV@q\277\266\10\300"..., 4096) = 4096
select(8, [3], NULL, NULL, {180, 0})    = 1 (in [3], left {179, 999999})
read(3, "S\247z\341\347/\347j\247\242\252\347\350,_\216wm\234t:\232\306\266\22I\363\6\245\310Z\310"..., 4096) = 4096
select(8, [3], NULL, NULL, {180, 0})    = 1 (in [3], left {179, 999999})
read(3, "\6\215\321:v\234\264'@\320P\311\247\34\245\227\356E\371\375huU\27\20\16\342~\223p8\346"..., 4096) = 4096
select(8, [3], NULL, NULL, {180, 0})    = 1 (in [3], left {179, 999999})
read(3, "f\347\31\363=^w\330\10r\215\230\3629\242\0\2633\252\326\350\317\276$-\371\271\21x7lv"..., 4096) = 4096
select(8, [3], NULL, NULL, {180, 0})    = 1 (in [3], left {179, 999999})
read(3, "3\32571L\\C3\216 \21\314\245\35\331\322\203\23\227\247X\255\5)\315\\vK\302\345\204<"..., 4096) = 4096
select(8, [3], NULL, NULL, {180, 0})    = 1 (in [3], left {179, 999999})
read(3, "Gu\244\210\2110\230~\371]\330\306,\352\357\202xZ\267\377\33\31\32\241r\207\f\344\260g\306O"..., 4096) = 4096
select(8, [3], NULL, NULL, {180, 0})    = 1 (in [3], left {179, 999999})
read(3, "\345\306\f\276\265\\\327\247\0043\303\247P\325^6\4F\316w4\0230l\33`\10<@%!["..., 4096) = 4096
select(8, [3], NULL, NULL, {180, 0})    = 1 (in [3], left {179, 999998})
read(3, "\5r\301c\322Ax\311']\2479\226 \252\6i\20#\254\350\313\322\312d\224\237\242\24\252/\177"..., 4096) = 4096
select(8, [3], NULL, NULL, {180, 0})    = 1 (in [3], left {179, 999999})
read(3, "\325\346\356\1\270\34\\\323V\215.\214\324.\24'\361\373&E\207\nCh\337\334l\5zg\241\213"..., 4096) = 4096


for big file hosted on localhost (nginx)

HTTP mode, lwp 6.05, linux


On Sun Aug 12 15:15:03 2012, CowboyTim wrote:
> Information:
>    libwww-perl-6.04
>    perl v5.12.2 on x86_64-linux-gnu-thread-multi 
>    Linux wihiie 3.2.0-2-amd64 #1 SMP Sun Mar 4 22:48:17 UTC 2012 x86_64 
> GNU/Linux
> 
> When using LWP::UserAgent to connect to a http(s) webserver, the cpu 
> usage goes to 100% (per core fcourse) when waiting for data on that 
> socket. It's in fact an infinite loop that only quits when the socket 
> has an error.
> 
> Sample script:
> 
>   use strict; use warnings;
> 
>   use LWP::UserAgent;
> 
>   my $u = LWP::UserAgent->new(
>       ssl_opts => {verify_hostname => 0},
>   );
>   $u->get("https://127.0.0.1:1443/BIGFILE", ':content_cb' => sub {});
> 
> 
> This can be checked with strace, it loops only this:
>     
>      read(3, 0x13c5ff3, 5) = -1 EAGAIN (Resource temporarily 
> unavailable)
> 
> This is easily testable by using socat and use it as a TCP proxy (event 
> for HTTPS/SSL). One starts a socat and background it while a sample 
> script is downloading data. This is of course not a real world situation  
> as normally, networking is ok these days. The problem is that sometimes 
> networking isnt' great and, morover, when the data doesn't come in *fast 
> enough* it also consumes too much cpu cycles. Also, a loop like that 
> makes that the timeout parameters are impossible to implement and 
> enforce.
> 
> I've found multiple of those infinite like loops:
>    IO::Socket::SSL has one in readline() (even multiple copy-pasted 
> ones)
>    Net::HTTP has one which does a select+timeout infinite loop while 
> waiting for http response headers on a persistent chunked connection.
> 
> This particular one is in LWP::Protocol::http:
> 
> 409       READ:
> 410     {
> 411         $n = $socket->read_entity_body($buf, $size);
> 412             unless (defined $n) {
> 413                 redo READ if $!{EINTR} || $!{EAGAIN};
> 414                 die "read failed: $!";
> 415             }
> 416         redo READ if $n == -1;
> 417     }
> 
> 
> Net::HTTP::Methods' read_entity_body() does a nonblocking read and here 
> it's unchecked with select().
> 
> I must admit that this might be difficult to fix in LWP::UserAgent as 
> this module isn't probably ment to do stuff like that. Probably because 
> it's next to impossible to have an eventloop like AnyEvent in 
> LWP::UserAgent. With AnyEvent::HTTP this is next to perfect - however, 
> that lacks a few other things compared to LWP::UserAgent.
> 
> It is possible to have at least all read/write's banked with a decent 
> select() with a correct bitmask: the fd is known there. Even adding the 
> timeout var is perfectly possible. Same for Net::HTTP's select+timeout 
> call.
>    
> 
>   

From aardbeiplantje@gmail.com on 2013-12-10 22:41:49:

your destination keeps providing data, the cpu usage is normal then. It's
also not yet fixed in 6.05. If you want to test/verify this: run e.g. a
server in foreground mode and while it is transferring data, background it
with ctrl-Z. The client process will go to 100% cpu.


2013/12/10 Victor Efimov via RT <bug-libwww-perl@rt.cpan.org>

> <URL: https://rt.cpan.org/Ticket/Display.html?id=78920 >
>
> Can't reproduce.
>
> strace shows
>
> read(3,
> "\32&Z\323L\201|)>`J\34\2\243\251\35\334\373\226>Z\357\307\250\22p\v)Ux'x"...,
> 4096) = 4096
> select(8, [3], NULL, NULL, {180, 0})    = 1 (in [3], left {179, 999999})
> read(3,
> "\"\207%(\227\1\247\377\0009`\0264\374\211\243\232\257G\\8\240\223DyV@q\277\266\10\300"...,
> 4096) = 4096
> select(8, [3], NULL, NULL, {180, 0})    = 1 (in [3], left {179, 999999})
> read(3,
> "S\247z\341\347/\347j\247\242\252\347\350,_\216wm\234t:\232\306\266\22I\363\6\245\310Z\310"...,
> 4096) = 4096
> select(8, [3], NULL, NULL, {180, 0})    = 1 (in [3], left {179, 999999})
> read(3, "\6\215\321:v\234\264'@\320P\311\247\34\245\227\356E\371\375huU\27\20\16\342~\223p8\346"...,
> 4096) = 4096
> select(8, [3], NULL, NULL, {180, 0})    = 1 (in [3], left {179, 999999})
> read(3,
> "f\347\31\363=^w\330\10r\215\230\3629\242\0\2633\252\326\350\317\276$-\371\271\21x7lv"...,
> 4096) = 4096
> select(8, [3], NULL, NULL, {180, 0})    = 1 (in [3], left {179, 999999})
> read(3, "3\32571L\\C3\216
> \21\314\245\35\331\322\203\23\227\247X\255\5)\315\\vK\302\345\204<"...,
> 4096) = 4096
> select(8, [3], NULL, NULL, {180, 0})    = 1 (in [3], left {179, 999999})
> read(3,
> "Gu\244\210\2110\230~\371]\330\306,\352\357\202xZ\267\377\33\31\32\241r\207\f\344\260g\306O"...,
> 4096) = 4096
> select(8, [3], NULL, NULL, {180, 0})    = 1 (in [3], left {179, 999999})
> read(3,
> "\345\306\f\276\265\\\327\247\0043\303\247P\325^6\4F\316w4\0230l\33`\10<@%!["...,
> 4096) = 4096
> select(8, [3], NULL, NULL, {180, 0})    = 1 (in [3], left {179, 999998})
> read(3, "\5r\301c\322Ax\311']\2479\226
> \252\6i\20#\254\350\313\322\312d\224\237\242\24\252/\177"..., 4096) = 4096
> select(8, [3], NULL, NULL, {180, 0})    = 1 (in [3], left {179, 999999})
> read(3,
> "\325\346\356\1\270\34\\\323V\215.\214\324.\24'\361\373&E\207\nCh\337\334l\5zg\241\213"...,
> 4096) = 4096
>
>
> for big file hosted on localhost (nginx)
>
> HTTP mode, lwp 6.05, linux
>
>
>

From victor@vsespb.ru on 2013-12-10 23:12:47:

I ran server

socat TCP-LISTEN:8001,crlf SYSTEM:"echo HTTP/1.0 200; echo Content-Type\: text/plain; echo; cat /home/somehugefile"

then ran client (i.e. code you posted) with strace.

then I Ctrl-Z server. Client just stopped. I brought server to foreground. Client continue execution. Don't see an issue.

On Wed Dec 11 02:41:49 2013, CowboyTim wrote:
> your destination keeps providing data, the cpu usage is normal then.
> It's
> also not yet fixed in 6.05. If you want to test/verify this: run e.g.
> a
> server in foreground mode and while it is transferring data,
> background it
> with ctrl-Z. The client process will go to 100% cpu.
> 
> 
> 2013/12/10 Victor Efimov via RT <bug-libwww-perl@rt.cpan.org>
> 
> > <URL: https://rt.cpan.org/Ticket/Display.html?id=78920 >
> >
> > Can't reproduce.
> >
> > strace shows
> >
> > read(3,
> > "\32&Z\323L\201|)>`J\34\2\243\251\35\334\373\226>Z\357\307\250\22p\v)Ux'x"...,
> > 4096) = 4096
> > select(8, [3], NULL, NULL, {180, 0})    = 1 (in [3], left {179,
> > 999999})
> > read(3,
> > "\"\207%(\227\1\247\377\0009`\0264\374\211\243\232\257G\\8\240\223DyV@q\277\266\10\300"...,
> > 4096) = 4096
> > select(8, [3], NULL, NULL, {180, 0})    = 1 (in [3], left {179,
> > 999999})
> > read(3,
> > "S\247z\341\347/\347j\247\242\252\347\350,_\216wm\234t:\232\306\266\22I\363\6\245\310Z\310"...,
> > 4096) = 4096
> > select(8, [3], NULL, NULL, {180, 0})    = 1 (in [3], left {179,
> > 999999})
> > read(3,
> > "\6\215\321:v\234\264'@\320P\311\247\34\245\227\356E\371\375huU\27\20\16\342~\223p8\346"...,
> > 4096) = 4096
> > select(8, [3], NULL, NULL, {180, 0})    = 1 (in [3], left {179,
> > 999999})
> > read(3,
> > "f\347\31\363=^w\330\10r\215\230\3629\242\0\2633\252\326\350\317\276$-
> > \371\271\21x7lv"...,
> > 4096) = 4096
> > select(8, [3], NULL, NULL, {180, 0})    = 1 (in [3], left {179,
> > 999999})
> > read(3, "3\32571L\\C3\216
> > \21\314\245\35\331\322\203\23\227\247X\255\5)\315\\vK\302\345\204<"...,
> > 4096) = 4096
> > select(8, [3], NULL, NULL, {180, 0})    = 1 (in [3], left {179,
> > 999999})
> > read(3,
> > "Gu\244\210\2110\230~\371]\330\306,\352\357\202xZ\267\377\33\31\32\241r\207\f\344\260g\306O"...,
> > 4096) = 4096
> > select(8, [3], NULL, NULL, {180, 0})    = 1 (in [3], left {179,
> > 999999})
> > read(3,
> > "\345\306\f\276\265\\\327\247\0043\303\247P\325^6\4F\316w4\0230l\33`\10<@%!["...,
> > 4096) = 4096
> > select(8, [3], NULL, NULL, {180, 0})    = 1 (in [3], left {179,
> > 999998})
> > read(3, "\5r\301c\322Ax\311']\2479\226
> > \252\6i\20#\254\350\313\322\312d\224\237\242\24\252/\177"..., 4096) =
> > 4096
> > select(8, [3], NULL, NULL, {180, 0})    = 1 (in [3], left {179,
> > 999999})
> > read(3,
> > "\325\346\356\1\270\34\\\323V\215.\214\324.\24'\361\373&E\207\nCh\337\334l\5zg\241\213"...,
> > 4096) = 4096
> >
> >
> > for big file hosted on localhost (nginx)
> >
> > HTTP mode, lwp 6.05, linux
> >
> >
> >


From aardbeiplantje@gmail.com on 2013-12-11 23:35:05:

You're right the strace is ok too (shouldn've noticed it immediately). This
problem is actually fixed in Net::HTTP 6.04 onwards. The loop without a
select() was in Net::HTTP 6.03. So the error wasn't in libwww-perl itself,
but in the Net::HTTP::Methods read_entity_biody(). The rt ticket can be
closed.


2013/12/11 Victor Efimov via RT <bug-libwww-perl@rt.cpan.org>

> <URL: https://rt.cpan.org/Ticket/Display.html?id=78920 >
>
> I ran server
>
> socat TCP-LISTEN:8001,crlf SYSTEM:"echo HTTP/1.0 200; echo Content-Type\:
> text/plain; echo; cat /home/somehugefile"
>
> then ran client (i.e. code you posted) with strace.
>
> then I Ctrl-Z server. Client just stopped. I brought server to foreground.
> Client continue execution. Don't see an issue.
>
> On Wed Dec 11 02:41:49 2013, CowboyTim wrote:
> > your destination keeps providing data, the cpu usage is normal then.
> > It's
> > also not yet fixed in 6.05. If you want to test/verify this: run e.g.
> > a
> > server in foreground mode and while it is transferring data,
> > background it
> > with ctrl-Z. The client process will go to 100% cpu.
> >
> >
> > 2013/12/10 Victor Efimov via RT <bug-libwww-perl@rt.cpan.org>
> >
> > > <URL: https://rt.cpan.org/Ticket/Display.html?id=78920 >
> > >
> > > Can't reproduce.
> > >
> > > strace shows
> > >
> > > read(3,
> > >
> "\32&Z\323L\201|)>`J\34\2\243\251\35\334\373\226>Z\357\307\250\22p\v)Ux'x"...,
> > > 4096) = 4096
> > > select(8, [3], NULL, NULL, {180, 0})    = 1 (in [3], left {179,
> > > 999999})
> > > read(3,
> > > "\"\207%(\227\1\247\377\0009`\0264\374\211\243\232\257G\\8\240\223DyV@q
> \277\266\10\300"...,
> > > 4096) = 4096
> > > select(8, [3], NULL, NULL, {180, 0})    = 1 (in [3], left {179,
> > > 999999})
> > > read(3,
> > >
> "S\247z\341\347/\347j\247\242\252\347\350,_\216wm\234t:\232\306\266\22I\363\6\245\310Z\310"...,
> > > 4096) = 4096
> > > select(8, [3], NULL, NULL, {180, 0})    = 1 (in [3], left {179,
> > > 999999})
> > > read(3,
> > > "\6\215\321:v\234\264'@
> \320P\311\247\34\245\227\356E\371\375huU\27\20\16\342~\223p8\346"...,
> > > 4096) = 4096
> > > select(8, [3], NULL, NULL, {180, 0})    = 1 (in [3], left {179,
> > > 999999})
> > > read(3,
> > > "f\347\31\363=^w\330\10r\215\230\3629\242\0\2633\252\326\350\317\276$-
> > > \371\271\21x7lv"...,
> > > 4096) = 4096
> > > select(8, [3], NULL, NULL, {180, 0})    = 1 (in [3], left {179,
> > > 999999})
> > > read(3, "3\32571L\\C3\216
> > > \21\314\245\35\331\322\203\23\227\247X\255\5)\315\\vK\302\345\204<"...,
> > > 4096) = 4096
> > > select(8, [3], NULL, NULL, {180, 0})    = 1 (in [3], left {179,
> > > 999999})
> > > read(3,
> > >
> "Gu\244\210\2110\230~\371]\330\306,\352\357\202xZ\267\377\33\31\32\241r\207\f\344\260g\306O"...,
> > > 4096) = 4096
> > > select(8, [3], NULL, NULL, {180, 0})    = 1 (in [3], left {179,
> > > 999999})
> > > read(3,
> > >
> "\345\306\f\276\265\\\327\247\0043\303\247P\325^6\4F\316w4\0230l\33`\10<@%!["...,
> > > 4096) = 4096
> > > select(8, [3], NULL, NULL, {180, 0})    = 1 (in [3], left {179,
> > > 999998})
> > > read(3, "\5r\301c\322Ax\311']\2479\226
> > > \252\6i\20#\254\350\313\322\312d\224\237\242\24\252/\177"..., 4096) =
> > > 4096
> > > select(8, [3], NULL, NULL, {180, 0})    = 1 (in [3], left {179,
> > > 999999})
> > > read(3,
> > >
> "\325\346\356\1\270\34\\\323V\215.\214\324.\24'\361\373&E\207\nCh\337\334l\5zg\241\213"...,
> > > 4096) = 4096
> > >
> > >
> > > for big file hosted on localhost (nginx)
> > >
> > > HTTP mode, lwp 6.05, linux
> > >
> > >
> > >
>
>
>
>

From mithaldu@cpan.org on 2014-04-23 18:26:59:

This issue still exists, and is, to make it worse, a heisenbug. Meaning reproduction of the issue will not be possible with simple methods.

When making requests with certain parameters, LWP::Protocol::http still falls into an endless loop when trying to retrieve data after the the response has already been fully downloaded, getting EAGAIN endlessly from a sysread call.

In my case i have the following situation:

- Windows 7
- ActivePerl
- SOAP::Lite
- SOAP server with SSL connection
- VPN connection that is rather slow
- 3970 byte response (3309 body + headers) from SOAP server

Since this happened on linux as well i am fairly sure the first two factors can be ruled out. It is however important to note that they wildly differ from the original report, putting the fault here squarely on the network handling in perl, instead of the system environment.

Further, SOAP::Lite might be a factor. However if it is, i request assistance in pinpointing what it is doing wrong.

SSL might be a factor, since it increases the CPU needs overall.

The VPN connection, or rather, its low speed, is definitely a factor. This is based on the fact that the exact same code worked perfectly fine when run on a machine that was on the same network as the server.

The response size is also definitely an issue, since smaller responses with an otherwise identical configuration did not cause an endless loop.

My local hack to fix the situation is embodied in this diff:


diff --git a/lib/LWP/Protocol/http.pm b/lib/LWP/Protocol/http.pm
index a75e147..01157f6 100644
--- a/lib/LWP/Protocol/http.pm
+++ b/lib/LWP/Protocol/http.pm
@@ -453,6 +453,7 @@ sub request
        my $n;
       READ:
        {
+            select(undef, undef, undef, 0.25);
            $n = $socket->read_entity_body($buf, $size);
             unless (defined $n) {
                 redo READ if $!{EINTR} || $!{EAGAIN} || $!{ENOTTY};


There are two notable things about this change:

1. The sleep has to occur before the read. Putting it on the line directly after the read_entity_body line still results in an endless loop, though one that does not hammer the CPU. Higher sleep time values there do not help, even a 10 second sleep after the read_entity_body line causes an endless loop. So it must come before it.

2. On my system smaller values for the sleep did not suffice. With a sleep time of 0.1 the endless loop still occurred, just with less CPU usage. The value of 0.25 was necessary on my machine to gain reliability.

From mitch@cgarbs.de on 2014-04-30 21:24:18:

As this bug has been called "Heisenbug" and hard to reproduce:
The twitter-plugin "twirssi" for the irssi IRC client suffers from
this, see this bug report:  https://github.com/zigdon/twirssi/issues/75

On my box I sometimes get multiple endless loops per day while on
other days everything is peaceful.

The constellation here is always:

 - HTTPS/SSL
 - connections to *.twitter.com - connections can be slow or sluggish ;-)

System:

 - Linux (Debian stable)
 - libwww-perl 6.04
 - Net::Twitter (current version from CPAN)

Regards
Christian
-- 
....Christian.Garbs.....................................http://www.cgarbs.de

           n   -on         8c       Noch mehr       lde.alt.rec.ascii-art
    ().    cc"-/7       __/~\__     abstrakte       l
   (O )o    "c__)      (((\_/)))   Gummihühner   .'"l .'"l l"'.'"l _ .'"l
    (( )Oo. ,-"<_  cgmm  _) (_      gibt's in    `._l `._l l  `._l   `._l

From xenic@basen.net on 2014-12-19 22:34:20:

Hi,

Hit this bug on a Raspberry running: Linux pirouter 3.12.28+ #709 PREEMPT Mon Sep 8 15:28:00 BST 2014 armv6l GNU/Linux

My client is doing multiple HTTPS PUTs to a remote server and (rough guesstimate) one in five of them gets stuck in a busy loop:

root@pirouter:~# strace -v -p 17160
Process 17160 attached - interrupt to quit
read(4, 0x192ae53, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
read(4, 0x192ae53, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
read(4, 0x192ae53, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
read(4, 0x192ae53, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
read(4, 0x192ae53, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
read(4, 0x192ae53, 5)                   = -1 EAGAIN (Resource temporarily unavailable)
read(4, 0x192ae53, 5)                   = -1 EAGAIN (Resource temporarily unavailable)

This seems to clear after a moment (20-30seconds), but constantly happens again on a subsequent request.


If I change from HTTPS to HTTP this does not happen (keeping everything else the same).

I'm able to constantly reproduce this (over reboots of the linux box in question) and can provide additional debug information if someone is able to direct me.




Perl version:

root@pirouter:~# perl -v

This is perl 5, version 14, subversion 2 (v5.14.2) built for arm-linux-gnueabihf-thread-multi-64int

libwww version:

root@pirouter:~# dpkg --status libwww-perl
Package: libwww-perl
Status: install ok installed
Priority: optional
Section: perl
Installed-Size: 412
Maintainer: Debian Perl Group <pkg-perl-maintainers@lists.alioth.debian.org>
Architecture: all
Version: 6.04-1
Depends: perl, ca-certificates, libencode-locale-perl, libfile-listing-perl, libhtml-parser-perl, libhtml-tagset-perl, libhtml-tree-perl, libhttp-cookies-perl, libhttp-date-perl, libhttp-message-perl, libhttp-negotiate-perl, liblwp-mediatypes-perl, liblwp-protocol-https-perl, libnet-http-perl, liburi-perl, libwww-robotrules-perl, netbase
Recommends: libhtml-form-perl, libhtml-format-perl, libhttp-daemon-perl, libmailtools-perl
Suggests: libauthen-ntlm-perl
Breaks: fusioninventory-agent (<< 2.1.8-2), gsutil (<< 3.1-1), libfrontier-rpc-perl (<< 0.07b4-6), libhttp-daemon-ssl-perl (<< 1.04-3), libhttp-proxy-perl (<< 0.24-2), libhttp-request-ascgi-perl (<< 1.2-2), libhttp-request-params-perl (<< 1.01-6), libjson-rpc-perl (<< 0.96-3), libpoe-perl (<< 2:1.2990-2), librpc-xml-perl (<< 0.74-2), libsoap-lite-perl (<< 0.7.12-3), libwww-mechanize-formfiller-perl (<< 0.10-2), libwww-mechanize-perl (<< 1.66-2), satutils (<= 0.6), tidy-proxy (<< 0.97-4)
Description: simple and consistent interface to the world-wide web
 libwww-perl (also known as LWP) is a collection of Perl modules that provide
 a simple and consistent programming interface (API) to the World-Wide Web.
 The main focus of the library is to provide classes and functions that allow
 you to write WWW clients. It also contains general purpose modules, as well
 as a simple HTTP/1.1-compatible server implementation.
Homepage: http://search.cpan.org/dist/libwww-perl/



From mirq-boogs@rere.qmqm.pl on 2014-12-22 11:41:04:

I also tripped on this bug on latest Debian wheezy. Maybe it's IO::Socket::SSL at fault?
I worked aroud the problem by adding following to the script's environment:

PERL_NET_HTTPS_SSL_SOCKET_CLASS=Net::SSL

Best Regards,
Micha� Miros�aw

From mirq-boogs@rere.qmqm.pl on 2014-12-22 11:43:42:

I also tripped on this bug on latest Debian wheezy. Maybe it's IO::Socket::SSL at fault?
I worked aroud the problem by adding following to the script's environment:

PERL_NET_HTTPS_SSL_SOCKET_CLASS=Net::SSL

Best Regards,
Micha� Miros�aw
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment