utACK (plans to test this soon).
Not sure about the insides of getblocktemplate, but hows does the rpctimeout affect the long poll?

Not sure about the insides of getblocktemplate, but hows does the rpctimeout affect the long poll?

On the server side it doesn't affect that - it doesn't spend time waiting for input from the client.
On the client side, the request will time out if the reply takes longer than rpcclienttimeout.

Unfortunately I'm 0/2 on testing these. I couldn't recreate the SIGPIPE issue, in master or here, so thats's a start. But I still get what looks like a timeout from getblocktemplate_longpoll.py and I still get errors spewed to stdout when I don't have an IPv6 address.

EDIT: as per IRC:

• SIGPIPE appears to be an OS X issue, which is why I couldn't recreate.
• older versions of libevent don't support turning off the function call to turn off debugging

From IRC:

<morcos> regarding the rpc timeouts..  before 6695, you could fix the problem by starting the bitcoind's in the python tests with -rpctimeout=1500 (or whatever)
<morcos> doesn't that imply that somehow it was the timeout on the server end that was the problem?

Looks like the issue is not in bitcoin-cli but in the python http functionality that cannot cope with disconnects between requests (as said by @sdaftuar ). Which would be strange, but I'll take a look at it.

The rpcbind.py test hang in #6655 is caused by bitcoin-cli being unable to connect to IPv6 IPs. Not sure why. Also not sure whether this affects all libevent versions. But I can reproduce it with libevent 0x02001500 on Ubuntu 14.04 (which is relatively ancient).

SIGPIPE appears to be an OS X issue, which is why I couldn't recreate.

I could reproduce it on debian as well. Use a bitcoin-cli command like getblocktemplate or getrawmempool and enter ctrl-C short after sending-off the command. Very hard to reproduce (requires a few tries).
With a script it would probably easy.

The SIGPIPE gets emitted when bitcoind starts to write to a closed socket (ctrl-c will terminate bitcoin-cli which ends up in writing to a closed socket on the server side).

@laanwj I know I said I didn't care, but I tracked down the silly warning messages. We need to call event_set_log_callback. I tried it and it works.

concept ACK

@morcos Ah, that'd allow redirecting the messages to our own log. That makes sense in addition to what is done here.

Edit: done, the option is -debug=libevent now

The Python BadStatusLine on disconnect issue sounds like https://bugs.python.org/issue3566 "httplib persistent connections violate MUST in RFC2616 sec 8.1.4."

This was fixed in Python 3.5.

I've pushed a commit that should work around it.

ACK (modulo missing newlines)

Fixed the newline issue (thanks @morcos), removed a spurious change in util.py