05:08:18 hi 13:07:15 hi 14:18:16 I'm getting `no connection to daemon` error a ton from the monero-wallet-rpc. I'm pretty sure the daemon I'm using is working correctly and I don't think think it's a problem with my connectivity. I'm using the RPC in my application and a ton of users are reporting getting this error. Could there be another reason? 14:18:16 ``` 14:18:16 ./monero-wallet-rpc --rpc-bind-port 28088 --wallet-file ./monero-data/swap-tool-blockchain-monitoring-wallet --daemon-address stagenet.community.rino.io:38081 --stagenet --disable-rpc-login --password "" 14:18:17 This is the RPC monero wallet. It needs to connect to a monero 14:18:17 daemon to work correctly. 14:18:18 Monero 'Fluorine Fermi' (v0.18.1.2-release) 14:18:18 Logging to ./monero-wallet-rpc.log 14:18:19 2023-12-09 14:12:45.915 W Loading wallet... 14:18:19 2023-12-09 14:12:48.199 W Loaded wallet keys file, with public address: 52PeG4BkPFT28Pt2JDG95uFrgGCsrYdE7dLhFan2Sj9fPCPBkRZEKiAHeQqoEnDKidYN5xuso2fAxCSWeJGQDnoDUUv3oig 14:18:20 2023-12-09 14:13:46.367 E !r. THROW EXCEPTION: tools::error::no_connection_to_daemon 14:18:20 2023-12-09 14:13:46.376 E !r. THROW EXCEPTION: tools::error::no_connection_to_daemon 14:18:21 2023-12-09 14:13:46.376 E !r. THROW EXCEPTION: tools::error::no_connection_to_daemon 14:18:21 2023-12-09 14:13:46.376 E !r. THROW EXCEPTION: tools::error::no_connection_to_daemon 14:18:22 2023-12-09 14:13:46.378 E pull_blocks failed, try_count=3 14:18:22 2023-12-09 14:13:46.378 E Initial refresh failed: no connection to daemon 14:18:23 2023-12-09 14:13:46.379 I Binding on 127.0.0.1 (IPv4):28088 14:21:04 Check the node.. 14:21:40 "pretty sure daemon is working correctly" > i only see this issue when (if) my node is unreachable 14:21:51 I have 2 question. I hope someone can nudge me in the right direction. 14:21:51 1. I'm getting `no connection to daemon` error a ton from the monero-wallet-rpc. I'm pretty sure the daemon I'm using is working correctly and I don't think think it's a problem with my connectivity. I'm using the RPC in my application and a ton of users are reporting getting this error. Could there be another reason? 14:21:52 ``` 14:21:52 ./monero-wallet-rpc --rpc-bind-port 28088 --wallet-file ./monero-data/swap-tool-blockchain-monitoring-wallet --daemon-address stagenet.community.rino.io:38081 --stagenet --disable-rpc-login --password "" 14:21:53 This is the RPC monero wallet. It needs to connect to a monero 14:21:53 daemon to work correctly. 14:21:54 Monero 'Fluorine Fermi' (v0.18.1.2-release) 14:21:54 Logging to ./monero-wallet-rpc.log 14:21:55 2023-12-09 14:12:45.915 W Loading wallet... 14:21:55 2023-12-09 14:12:48.199 W Loaded wallet keys file, with public address: 52PeG4BkPFT28Pt2JDG95uFrgGCsrYdE7dLhFan2Sj9fPCPBkRZEKiAHeQqoEnDKidYN5xuso2fAxCSWeJGQDnoDUUv3oig 14:21:56 2023-12-09 14:13:46.367 E !r. THROW EXCEPTION: tools::error::no_connection_to_daemon 14:21:56 2023-12-09 14:13:46.376 E !r. THROW EXCEPTION: tools::error::no_connection_to_daemon 14:21:57 2023-12-09 14:13:46.376 E !r. THROW EXCEPTION: tools::error::no_connection_to_daemon 14:21:57 2023-12-09 14:13:46.376 E !r. THROW EXCEPTION: tools::error::no_connection_to_daemon 14:21:58 2023-12-09 14:13:46.378 E pull_blocks failed, try_count=3 14:21:58 2023-12-09 14:13:46.378 E Initial refresh failed: no connection to daemon 14:21:59 2023-12-09 14:13:46.379 I Binding on 127.0.0.1 (IPv4):28088 14:21:59 2023-12-09 14:13:46.944 W Starting wallet RPC server 14:22:22 monero-wallet-rpc + remote node is asking for problems 14:22:37 get height doesnt block, its a simple json call 14:23:09 Using rpc "remotely" but on same lan, my btcpayserver has been up for weeks without a hiccup 14:24:17 What's a better alternative? I'm using rust for the application that controls the RPC 14:24:31 Rpc in a vm, connected to node and node _omly_ has wifi connectivity 14:24:47 2. --no-initial-sync https://github.com/monero-project/monero/pull/8355 14:25:03 moneromooo thnx 14:25:49 curl json http://node.ip:port/get_info for height 14:26:06 if the node is on the same LAN, it's not really remote is it. I used to run with monero-wallet-rpc going 24/7 with a remote node for monerodirect.com 14:26:13 never had any problems with that 14:26:55 its remote in that its traveling over a wireless network that has downtime 14:28:21 hm. you could just run it on the same box then. I had everything running on a Geekbox SBC. node, 128GB microSD card, wallet. plugged into a USB powerbank, it could run for 2 days straight if the AC power went out. 14:28:45 Thank you! That does seem to be what I need. Will this also ensure that I can query the current sync height while it's syncing after I call `refresh` without it hanging or is this only applicable to the first refresh when the wallet is opened? 14:29:10 get_info json request lolz 14:29:14 that included a 4G dongle too, it would keep operating even if the local wifi went down 14:29:29 Or you mean the wallets sync orogress> 14:29:38 yes, but, the rpc wallet can still randomly hang xD 14:29:57 I want to get the current sync height not the blockchain height. 14:30:22 wallet sync height, correct? 14:30:53 will allow something like this yes https://github.com/plowsof/scrape_ccs_fr/blob/d4c197e79f8a92f860351bf137a5f1aec289bae6/get_overfunded.py#L41 14:32:39 Yeah I read your comment on Github. It's 100% the issue I have as well. Thank you! 14:33:55 In your code you do not call `refresh` at all. Will the wallet still sync up with the network, just slower and without blocking all RPC requests? 14:35:04 refresh is used to skip sync in the wallet redeem code, but ye should work combined with --no-initial-sync 14:37:27 start with --no-initial.. then wallet rpc is immediately available to receive the sync from height (refresh) command 14:41:57 "is immediately available to receive the sync from height (refresh) command". Can you elaborate on that? Do you mean that I can call get_height before calling refresh or while refresh is pending? I apologize if I'm repeating the same question over and over again. I just want to make sure. 14:43:54 i start wallet rpc and wait to see "Starting wallet RPC server" , then its ready (so not immediately per se) 14:44:20 No-initial just opens the wallet and leaves it "waiting for orders" - doesnt refresh until you order it to (?) 14:44:20 meaning you can run other rpc commands (height, create addr etc) before waiting to sync 14:44:40 (plow, please confirm) 14:46:00 without no-initial-sync , the wallet rpc server is started AFTER the open wallet file is fully synced, until then, its a black hole) 14:47:49 so its waiting for orders during sync (refresh + height just forces the wallets height.. so binarybaron should be able to query the wallets sync height after sending the refresh command 14:48:14 as long as the "Starting wallet RPC server" line is seen 14:48:40 if theres a more elegant way to "know what its ready" than reading lines in your terminal pls let me know lol 14:49:06 iterating over stdout seems hacky but works 14:51:28 you could also detect this error if stdout line contains "no connection to"... do something about it 14:51:55 Yeah I'm doing the same. You could also attempt to call `get_version` until you get a response. 14:53:01 wallet rpc has qwerks .. detecting when it freezes and force restarting / recovering from connection losses is most important 14:55:06 Are there better ways to integrate the same functionality without directly calling C++ functions? (specficially in rust) 16:06:52 BusyBoredom could provide some assistance (developer of payment processor in rust which doesnt use monero-wallet-rpc, rather, its own 'stuff') 16:19:00 binarybaron what is the goal of your project? 16:58:15 Its unstoppable swap gui 17:01:48 Ah cool. Well, AcceptXMR can't send transactions so I can't help with that part but if there are any questions about how to watch for incoming transactions without monero-wallet-rpc, I can definitely give pointers there 👍 17:04:05 Hes looking to grab the wallets sync height quickly 17:04:24 2. I want to display to the user how far the wallet has been synced. I assumed I could call `get_height` while my `refresh` call is pending but it seems that `get_height` is blocking while the wallet is syncing? How can I check how far the wallet has synced? 18:25:36 Ah, that's a problem I have not solved :( AcceptXMR doesnt maintain a wallet. The only wallet-like state it keeps is a list of previously used stealth addresses to mitigate the burning bug. 22:57:02 okay, this is two days late but here's the failed build log again: https://mesaoptimizer.com/failed_monero_build.txt 22:57:48 `ulimit -a` says that my openBSD machine has a `stack (kbytes)` of 4096. I believe that this is what some people believe is causing this issue 23:07:09 OOM seems more likely to be heap rather than stack, unless they calloc and check. 23:07:52 You could try adding some swap, possibly. I assume you don't run with -j, but if you do, don't :) 23:08:34 oh, I don't, it's a pure `gmake` 23:08:52 Compiling wallet2.cpp with -O0 should also use less memory. make VERBOSE=1 will print the command line. Copy it, add -O0 at the end. Then make again. 23:08:53 hmm. I could try doubling the swap to see what happens 23:09:18 You'd probably need to do it for core_rpc_server.cpp as well. 23:09:53 If you think it's the stack, did you try modifying the limit ? 23:10:13 4 MB seems pretty large, but you never know. 23:10:26 Oh wait. 4 kB. Not very large. 23:10:46 Oh no 4 MB. Large. Sigh. 23:10:46 oh no, it is 4M 23:11:14 I haven't yet succeeded in changing the stack size for my user so I could run a build to test this hypothesis 23:11:26 I'll first try increasing swap 23:11:37 How much free RAM ? 23:11:54 4 GB ought to be enough. 23:12:08 ...for anybody... 23:12:09 I have 11G Free as of now, based on `top` 23:12:20 and 16G swap 23:12:23 OK, then maybe you're right about stack :D 23:12:45 hmm I see. It was someone else here who said I should increase stack size and check, just to be clear 23:27:23 okay, 8M stack size is also not enough 23:27:39 let's try 16M 23:36:05 16M failed, now trying 32M (well, I added 256M to /etc/login.conf but `ulimit -a` seems to report 32M regardless) 23:41:23 failed yet again 23:41:48 I also do not think an OOM occurred, given the fact that IIRC swap wasn't even touched before the failure of the build 23:50:19 `make VERBOSE=1` gives me the line to compile `wallet2.cpp` -- unfortunately running that line separately with `-O0` still results in the same error