Skip Menu |
 

This queue is for tickets about the libwww-perl CPAN distribution.

Report information
The Basics
Id: 78920
Status: resolved
Priority: 0/
Queue: libwww-perl

People
Owner: Nobody in particular
Requestors: aardbeiplantje [...] gmail.com
Cc: victor [...] vsespb.ru
AdminCc:

Bug Information
Severity: Normal
Broken in: 6.04
Fixed in: (no value)



Subject: high cpu usage when waiting for data on the destination socket
Download (untitled) / with headers
text/plain 2.4k
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.
Download (untitled) / with headers
text/plain 4.4k
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: Show quoted text
> 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. > > >
Subject: Re: [rt.cpan.org #78920] high cpu usage when waiting for data on the destination socket
Date: Tue, 10 Dec 2013 23:41:37 +0100
To: bug-libwww-perl [...] rt.cpan.org
From: Tim Aerts <aardbeiplantje [...] gmail.com>
Download (untitled) / with headers
text/plain 2.3k
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> Show quoted text
> <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 > > >
Download (untitled) / with headers
text/plain 2.8k
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: Show quoted text
> 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 > > > > > >
Subject: Re: [rt.cpan.org #78920] high cpu usage when waiting for data on the destination socket
Date: Thu, 12 Dec 2013 00:34:54 +0100
To: bug-libwww-perl [...] rt.cpan.org
From: Tim Aerts <aardbeiplantje [...] gmail.com>
Download (untitled) / with headers
text/plain 3.4k
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> Show quoted text
> <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 > > > > > > > > >
> > > >
Download (untitled) / with headers
text/plain 2.4k
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.
Subject: [rt.cpan.org #78920] twirssi suffers from this
Date: Wed, 30 Apr 2014 23:18:00 +0200
To: bug-libwww-perl [...] rt.cpan.org
From: Christian Garbs <mitch [...] cgarbs.de>
Download (untitled) / with headers
text/plain 905b
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
Subject: [rt.cpan.org #78920]
Date: Fri, 19 Dec 2014 22:33:56 +0000
To: "bug-libwww-perl [...] rt.cpan.org" <bug-libwww-perl [...] rt.cpan.org>
From: Ilkka Kaakkola <xenic [...] basen.net>
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/
Subject: [rt.cpan.org #78920]
Date: Mon, 22 Dec 2014 12:35:46 +0100
To: bug-libwww-perl [...] rt.cpan.org
From: Michał Mirosław <mirq-boogs [...] rere.qmqm.pl>
Download (untitled) / with headers
text/plain 241b
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
Subject: [rt.cpan.org #78920]
Date: Mon, 22 Dec 2014 12:35:46 +0100
To: bug-libwww-perl [...] rt.cpan.org
From: Michał Mirosław <mirq-boogs [...] rere.qmqm.pl>
Download (untitled) / with headers
text/plain 241b
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


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.