Skip to content
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

p2pool hangs if monerod is not running #183

Closed
bladedoyle opened this issue Jul 4, 2022 · 4 comments
Closed

p2pool hangs if monerod is not running #183

bladedoyle opened this issue Jul 4, 2022 · 4 comments

Comments

@bladedoyle
Copy link
Contributor

bladedoyle commented Jul 4, 2022

If there is nothing listening on port 18081 when p2ppol make an rpc call (get_info) there is no connection timeout triggered and p2pool hangs forever. This can be reproduced on linux by simply starting p2pool when monerod is not running:

./p2pool --host 127.0.0.1 --wallet 44MnN1f3Eto8DZYUWuE5XZNUtE3vcRzt2j6PzqWpPau34e6Cf4fAxt6X2MBmrm6F9YMEiMNjN6W4Shn4pLcfNAja621jwyg

libuv is calling epoll_wait with infinite timeout:
0x00007ffff7bf146e in epoll_wait (epfd=4, events=0x7fffffff9ac0, maxevents=1024, timeout=-1) at ../sysdeps/unix/sysv/linux/epoll_wait.c:30

Im guessing there is supposed to be some kind of libuv timeout triggered for this case, but none is.

In contrast, if something is listening on the monero rpc port 18081 but fails to reposond, there is a timeout triggered and p2pool does retry the call. This can be reproduced on linux using socat:

shell 1: $ socat TCP-LISTEN:18081 stdout
shell 2: $ ./p2pool --host 127.0.0.1 --wallet 44MnN1f3Eto8DZYUWuE5XZNUtE3vcRzt2j6PzqWpPau34e6Cf4fAxt6X2MBmrm6F9YMEiMNjN6W4Shn4pLcfNAja621jwyg
shell 1:

POST /json_rpc HTTP/1.1
Host: 127.0.0.1:18081
Accept: */*
Content-Length: 46
Content-Type: application/x-www-form-urlencoded

{"jsonrpc":"2.0","id":"0","method":"get_info"}

shell 2:

2022-07-04 21:49:35.1356 P2Pool get_info RPC request failed: error Timeout was reached, trying again in 1 second

But then, the socat process exits and nothing is listening on port 18081 and the second call made by p2pool hangs and waits forever. It appears that libuv timeouts are working for connected sockets that dont reply in time, but not for socket connection timeouts when no process is listening at all.

Note that even if monerod is started after p2pool hangs while attempting a connection, p2pool does not recover and must be restarted before it makes the next rpc request.

@SChernykh
Copy link
Owner

64baf66

@bladedoyle
Copy link
Contributor Author

Yes, confirmed this appears to resolve the issue. Thanks!

@bladedoyle bladedoyle reopened this Jul 5, 2022
@bladedoyle
Copy link
Contributor Author

This change does seem to have the side effect of dumping core:

2022-07-05 11:42:17.8808 P2Pool get_info RPC request failed: error Couldn't connect to server, trying again in 1 second
^C2022-07-05 11:42:18.8810 P2Pool caught SIGINT
2022-07-05 11:42:18.8810 P2Pool stopping
2022-07-05 11:42:18.8813 P2Pool get_info RPC request failed: error Couldn't connect to server, trying again in 1 second
Segmentation fault (core dumped)
Core was generated by `./p2pool --host 127.0.0.1 --wallet 44MnN1f3Eto8DZYUWuE5XZNUtE3vcRzt2j6PzqWpPau3'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  __GI___pthread_mutex_lock (mutex=0x10) at ../nptl/pthread_mutex_lock.c:67
67  ../nptl/pthread_mutex_lock.c: No such file or directory.
[Current thread is 1 (Thread 0x7f0812be4c00 (LWP 3843591))]
(gdb) where
#0  __GI___pthread_mutex_lock (mutex=0x10) at ../nptl/pthread_mutex_lock.c:67
#1  0x00007f081443d3bd in uv_mutex_lock ()
   from /lib/x86_64-linux-gnu/libuv.so.1
#2  0x000055cbea387dc8 in p2pool::MutexLock::MutexLock (handle=...,
    this=<optimized out>) at /xxx/p2pool/src/uv_util.h:29
#3  p2pool::CallOnLoop<p2pool::JSONRPCRequest::Call(const string&, int, const string&, const string&, p2pool::JSONRPCRequest::CallbackBase*, p2pool::JSONRPCRequest::CallbackBase*, uv_loop_t*)::<lambda()> >(uv_loop_t *, p2pool::JSONRPCRequest::<lambda()> &&) (loop=0x7f0814450260, callback=...)
    at /xxx/p2pool/src/uv_util.h:146
#4  0x000055cbea387c8e in p2pool::JSONRPCRequest::Call (address="127.0.0.1",
    port=18081,
    req="{\"jsonrpc\":\"2.0\",\"id\":\"0\",\"method\":\"get_info\"}", auth="",
    cb=0x55cbeab62020, close_cb=0x55cbeac95bd0, loop=0x7f0814450260)
    at /xxx/p2pool/src/json_rpc_request.cpp:368
#5  0x000055cbea413593 in p2pool::JSONRPCRequest::call<p2pool::p2pool::get_info()::<lambda(char const*, size_t)>, p2pool::p2pool::get_info()::<lambda(char const*, size_t)> > (loop=0x0, close_cb=..., cb=..., auth="", req=..., port=18081,
    address="127.0.0.1")
    at /xxx/p2pool/src/json_rpc_request.h:45
#6  p2pool::p2pool::get_info (this=0x7fffee5d9400)
    at /xxx/p2pool/src/p2pool.cpp:769
#7  0x000055cbea4133eb in p2pool::p2pool::<lambda(char const*, size_t)>::operato--Type <RET> for more, q to quit, c to continue without paging--
r()(const char *, size_t) const (__closure=0x55cbeab624e8,
    data=0x55cbeac94ec0 "Couldn't connect to server", size=26)
    at /xxx/p2pool/src/p2pool.cpp:779
#8  0x000055cbea426fa9 in p2pool::JSONRPCRequest::Callback<p2pool::p2pool::get_info()::<lambda(char const*, size_t)> >::operator()(const char *, size_t) (
    this=0x55cbeab624e0, data=0x55cbeac94ec0 "Couldn't connect to server",
    size=26) at /xxx/p2pool/src/json_rpc_request.h:33
#9  0x000055cbea386649 in p2pool::JSONRPCRequest::CurlContext::~CurlContext (
    this=0x55cbeac80fe0, __in_chrg=<optimized out>)
    at /xxx/p2pool/src/json_rpc_request.cpp:205
#10 0x000055cbea3878f8 in p2pool::JSONRPCRequest::CurlContext::on_close (
    h=0x55cbeac81138)
    at /xxx/p2pool/src/json_rpc_request.cpp:343
#11 0x00007f0814430909 in uv_run () from /lib/x86_64-linux-gnu/libuv.so.1
#12 0x000055cbea425297 in p2pool::p2pool::run (this=0x7fffee5d9400)
    at /xxx/p2pool/src/p2pool.cpp:1496
#13 0x000055cbea38f655 in main (argc=5, argv=0x7fffee5d99f8)
    at /xxx/p2pool/src/main.cpp:96

@SChernykh
Copy link
Owner

This is a different bug, fixed in 4ec0fe8

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants