<p​kl12:matrix.org> hi

<e​lementxx:matrix.org> hi

<b​inarybaron:matrix.org> 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?

<b​inarybaron:matrix.org> ```

<b​inarybaron:matrix.org> ./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 ""

<b​inarybaron:matrix.org> This is the RPC monero wallet. It needs to connect to a monero

<b​inarybaron:matrix.org> daemon to work correctly.

<b​inarybaron:matrix.org> Monero 'Fluorine Fermi' (v0.18.1.2-release)

<b​inarybaron:matrix.org> Logging to ./monero-wallet-rpc.log

<b​inarybaron:matrix.org> 2023-12-09 14:12:45.915 W Loading wallet...

<b​inarybaron:matrix.org> 2023-12-09 14:12:48.199 W Loaded wallet keys file, with public address: 52PeG4BkPFT28Pt2JDG95uFrgGCsrYdE7dLhFan2Sj9fPCPBkRZEKiAHeQqoEnDKidYN5xuso2fAxCSWeJGQDnoDUUv3oig

<b​inarybaron:matrix.org> 2023-12-09 14:13:46.367 E !r. THROW EXCEPTION: tools::error::no_connection_to_daemon

<b​inarybaron:matrix.org> 2023-12-09 14:13:46.376 E !r. THROW EXCEPTION: tools::error::no_connection_to_daemon

<b​inarybaron:matrix.org> 2023-12-09 14:13:46.376 E !r. THROW EXCEPTION: tools::error::no_connection_to_daemon

<b​inarybaron:matrix.org> 2023-12-09 14:13:46.376 E !r. THROW EXCEPTION: tools::error::no_connection_to_daemon

<b​inarybaron:matrix.org> 2023-12-09 14:13:46.378 E pull_blocks failed, try_count=3

<b​inarybaron:matrix.org> 2023-12-09 14:13:46.378 E Initial refresh failed: no connection to daemon

<b​inarybaron:matrix.org> 2023-12-09 14:13:46.379 I Binding on 127.0.0.1 (IPv4):28088

<o​frnxmr:monero.social> Check the node..

<o​frnxmr:monero.social> "pretty sure daemon is working correctly" > i only see this issue when (if) my node is unreachable

<b​inarybaron:matrix.org> I have 2 question. I hope someone can nudge me in the right direction.

<b​inarybaron:matrix.org> 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?

<b​inarybaron:matrix.org> ```

<b​inarybaron:matrix.org> ./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 ""

<b​inarybaron:matrix.org> This is the RPC monero wallet. It needs to connect to a monero

<b​inarybaron:matrix.org> daemon to work correctly.

<b​inarybaron:matrix.org> Monero 'Fluorine Fermi' (v0.18.1.2-release)

<b​inarybaron:matrix.org> Logging to ./monero-wallet-rpc.log

<b​inarybaron:matrix.org> 2023-12-09 14:12:45.915 W Loading wallet...

<b​inarybaron:matrix.org> 2023-12-09 14:12:48.199 W Loaded wallet keys file, with public address: 52PeG4BkPFT28Pt2JDG95uFrgGCsrYdE7dLhFan2Sj9fPCPBkRZEKiAHeQqoEnDKidYN5xuso2fAxCSWeJGQDnoDUUv3oig

<b​inarybaron:matrix.org> 2023-12-09 14:13:46.367 E !r. THROW EXCEPTION: tools::error::no_connection_to_daemon

<b​inarybaron:matrix.org> 2023-12-09 14:13:46.376 E !r. THROW EXCEPTION: tools::error::no_connection_to_daemon

<b​inarybaron:matrix.org> 2023-12-09 14:13:46.376 E !r. THROW EXCEPTION: tools::error::no_connection_to_daemon

<b​inarybaron:matrix.org> 2023-12-09 14:13:46.376 E !r. THROW EXCEPTION: tools::error::no_connection_to_daemon

<b​inarybaron:matrix.org> 2023-12-09 14:13:46.378 E pull_blocks failed, try_count=3

<b​inarybaron:matrix.org> 2023-12-09 14:13:46.378 E Initial refresh failed: no connection to daemon

<b​inarybaron:matrix.org> 2023-12-09 14:13:46.379 I Binding on 127.0.0.1 (IPv4):28088

<b​inarybaron:matrix.org> 2023-12-09 14:13:46.944 W Starting wallet RPC server

<p​lowsof:matrix.org> monero-wallet-rpc + remote node is asking for problems

<o​frnxmr:monero.social> get height doesnt block, its a simple json call

<o​frnxmr:monero.social> Using rpc "remotely" but on same lan, my btcpayserver has been up for weeks without a hiccup

<b​inarybaron:matrix.org> What's a better alternative? I'm using rust for the application that controls the RPC

<o​frnxmr:monero.social> Rpc in a vm, connected to node and node _omly_ has wifi connectivity

<p​lowsof:matrix.org> 2. --no-initial-sync monero-project/monero #8355

<p​lowsof:matrix.org> moneromooo thnx

<o​frnxmr:monero.social> curl json node.ip:port/get_info for height

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

never had any problems with that

<o​frnxmr:monero.social> its remote in that its traveling over a wireless network that has downtime

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.

<b​inarybaron:matrix.org> 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?

<o​frnxmr:monero.social> get_info json request lolz

that included a 4G dongle too, it would keep operating even if the local wifi went down

<o​frnxmr:monero.social> Or you mean the wallets sync orogress>

<p​lowsof:matrix.org> yes, but, the rpc wallet can still randomly hang xD

<b​inarybaron:matrix.org> I want to get the current sync height not the blockchain height.

<o​frnxmr:monero.social> wallet sync height, correct?

<p​lowsof:matrix.org> will allow something like this yes github.com/plowsof/scrape_ccs_fr/bl…5f1aec289bae6/get_overfunded.py#L41

<b​inarybaron:matrix.org> Yeah I read your comment on Github. It's 100% the issue I have as well. Thank you!

<b​inarybaron:matrix.org> 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?

<p​lowsof:matrix.org> refresh is used to skip sync in the wallet redeem code, but ye should work combined with --no-initial-sync

<p​lowsof:matrix.org> start with --no-initial.. then wallet rpc is immediately available to receive the sync from height (refresh) command

<b​inarybaron:matrix.org> "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.

<p​lowsof:matrix.org> i start wallet rpc and wait to see "Starting wallet RPC server" , then its ready (so not immediately per se)

<o​frnxmr:monero.social> No-initial just opens the wallet and leaves it "waiting for orders" - doesnt refresh until you order it to (?)

<o​frnxmr:monero.social> meaning you can run other rpc commands (height, create addr etc) before waiting to sync

<o​frnxmr:monero.social> (plow, please confirm)

<p​lowsof:matrix.org> without no-initial-sync , the wallet rpc server is started AFTER the open wallet file is fully synced, until then, its a black hole)

<p​lowsof:matrix.org> 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

<p​lowsof:matrix.org> as long as the "Starting wallet RPC server" line is seen

<p​lowsof:matrix.org> if theres a more elegant way to "know what its ready" than reading lines in your terminal pls let me know lol

<p​lowsof:matrix.org> iterating over stdout seems hacky but works

<p​lowsof:matrix.org> you could also detect this error if stdout line contains "no connection to"... do something about it

<b​inarybaron:matrix.org> Yeah I'm doing the same. You could also attempt to call `get_version` until you get a response.

<p​lowsof:matrix.org> wallet rpc has qwerks .. detecting when it freezes and force restarting / recovering from connection losses is most important

<b​inarybaron:matrix.org> Are there better ways to integrate the same functionality without directly calling C++ functions? (specficially in rust)

<p​lowsof:matrix.org> BusyBoredom could provide some assistance (developer of payment processor in rust which doesnt use monero-wallet-rpc, rather, its own 'stuff')

<b​usyboredom:monero.social> binarybaron what is the goal of your project?

<o​frnxmr:monero.social> Its unstoppable swap gui

<b​usyboredom:monero.social> 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 👍

<o​frnxmr:monero.social> Hes looking to grab the wallets sync height quickly

<o​frnxmr:monero.social> 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?

<b​usyboredom:monero.social> 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.

okay, this is two days late but here's the failed build log again: mesaoptimizer.com/failed_monero_build.txt

`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

OOM seems more likely to be heap rather than stack, unless they calloc and check.

You could try adding some swap, possibly. I assume you don't run with -j, but if you do, don't :)

oh, I don't, it's a pure `gmake`

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.

hmm. I could try doubling the swap to see what happens

You'd probably need to do it for core_rpc_server.cpp as well.

If you think it's the stack, did you try modifying the limit ?

4 MB seems pretty large, but you never know.

Oh wait. 4 kB. Not very large.

Oh no 4 MB. Large. Sigh.

oh no, it is 4M

I haven't yet succeeded in changing the stack size for my user so I could run a build to test this hypothesis

I'll first try increasing swap

How much free RAM ?

4 GB ought to be enough.

...for anybody...

I have 11G Free as of now, based on `top`

and 16G swap

OK, then maybe you're right about stack :D

hmm I see. It was someone else here who said I should increase stack size and check, just to be clear

okay, 8M stack size is also not enough

let's try 16M

16M failed, now trying 32M (well, I added 256M to /etc/login.conf but `ulimit -a` seems to report 32M regardless)

failed yet again

I also do not think an OOM occurred, given the fact that IIRC swap wasn't even touched before the failure of the build

`make VERBOSE=1` gives me the line to compile `wallet2.cpp` -- unfortunately running that line separately with `-O0` still results in the same error