-
m-relay
<jeffro256:monero.social> Yes this is the issue, working on a fix
-
selsta
tzadiko: please open a github issue if you think you found a bug so that it does not get lost
-
m-relay
<tzadiko:matrix.org> Im addressing it in my MR. It's part of the issue I'm working on. I'll detail it in the MR description
-
m-relay
<syntheticbird:monero.social> Tzadiko: just note that IRC cannot see the message to which you are replying. It's generally convention to type the name of the one you are trying to answer to (this will ping them).
-
m-relay
<tzadiko:matrix.org> Okay, I didn't know that. selsta, I will address this bug as part of my MR on an issue, and also detail it in the MR description.
-
m-relay
<ofrnxmr:xmr.mx> still a good idea to open it as an issue, as it can be a place for discussion about the specific problem
-
selsta
I'm unsure currently about 9838, we usually don't approve rewrite PRs
-
selsta
a simple PR that just fixes a bug will be easier to get approved
-
m-relay
<tzadiko:matrix.org> Ok
-
m-relay
-
m-relay
<tzadiko:matrix.org> Accompanying MR:
monero-project/monero #9842
-
m-relay
<maxxor:nitro.chat> hello everyone :)
-
m-relay
<maxxor:nitro.chat> Just to make sure: our nodes are getting stuck at different block heights at the time we receive the first pruned block from other peers right?
-
m-relay
<boog900:monero.social> Yes
-
m-relay
<jeffro256:monero.social> Working on a fix here:
monero-project/monero #9844
-
m-relay
<jeffro256:monero.social> Also, looks like there is problems with the Arch Linux build in the Trezor code:
github.com/monero-project/monero/ac…13901687577/job/38894790640?pr=9844
-
m-relay
<ofrnxmr:monero.social> I'm testing now. Deleted blockchain so resyncing
-
m-relay
<jeffro256:monero.social> You can also restart from where it gets stuck and sync from there. Works for me
-
m-relay
<jeffro256:monero.social> But yes, 0 to present syncing tests is also a good idea
-
m-relay
<monero.arbo:matrix.org>
tobtoht/monero a5fabe5
-
m-relay
<ofrnxmr:xmr.mx> Yeah, i mean, i deleted the blockchain like 5mins before i saw your pr :P
-
m-relay
<ofrnxmr:xmr.mx> jeffro256 just passed the height
-
m-relay
<ofrnxmr:xmr.mx> First 1.8m blocks in 1hr35min
-
gingeropolous
damn, xmrchain.net node went down.
-
gingeropolous
"Program terminated with signal SIGKILL, Killed." ... gdb says program no longer exists. I wonder if it got oom killed
-
Guest99
ola
-
m-relay
<ofrnxmr:xmr.mx> `2025-03-17 16:44:51.412 E Couldn't start RandomX seed thread Couldn't start RandomX seed thread`
-
m-relay
<ofrnxmr:xmr.mx> Could this be at all related to new pr, jeffro256 ? My node has crashed twice now (i'm using MONERO_RANDOMX_FULL_MEM=1)
-
m-relay
<ofrnxmr:xmr.mx> It synced np the other day
-
m-relay
<jeffro256:monero.social> Hmmmmm I don't know what the immediate cause would be..
-
m-relay
<jeffro256:monero.social> Do you have enough available RAM?
-
m-relay
<jeffro256:monero.social> It will allocate ~ 256 MB
-
m-relay
<ofrnxmr:xmr.mx> Yeah, over 10gb free
-
m-relay
<ofrnxmr:xmr.mx> only other variable between yesterdays and todays run is --sync-pruned-blocks. I'll turn off the pruned flag if it crashes again
-
m-relay
<ofrnxmr:xmr.mx> Oh, i also set --prep-blocks-threads=8
-
sech1
that error only happens when pthread_create() function fails. Maybe check if you hit the open files limit (ulimit -n)?
-
dukenukem
-12
-
sech1
or ulimit -r
-
m-relay
<jeffro256:monero.social> I thought it was `ulimit -u` ?
-
m-relay
<jeffro256:monero.social> There's also `cat /proc/sys/kernel/threads-max`
-
m-relay
<jeffro256:monero.social> `n` is for file descriptors, `r` is for scheduling priority IIUC
-
m-relay
<tzadiko:matrix.org> 100% of the tests are passing for me locally, but I'm having a couple of tests fail on the build. Including tests for gammapicker (select_outputs.exact_unlock_block), which I didn't touch. Any ideas? How should I proceed?
-
m-relay
<tzadiko:matrix.org> By 'fail on the build' I mean on Github.
-
m-relay
<jeffro256:monero.social> That test fails sporadically, especially when the system has bad entropy
-
ofrnxmr
Syncing master + dynamic block sync size (9494) + sync pruned fix (9844), using flags --prune-blockchain --sync-pruned-blocks --prep-blocks-threads=8 --batch-max-weight=3 ... master only has checkpoints til 3198000.. i'm at block 3100000 in 6hr10min
-
ofrnxmr
Was 21+hrs on prior runs.. not sure why so fast this time
-
m-relay
<jeffro256:monero.social> `--sync-pruned-blocks` should drop the majority of your bandwidth when in the checkpointed zone
-
m-relay
<ofrnxmr:xmr.mx> Network bandwidth isnt the issue
-
m-relay
<ofrnxmr:xmr.mx> I'm always downloaded well ahead (gbs) of the current blocks being synced
-
m-relay
-
m-relay
<ofrnxmr:xmr.mx> Example from the other day
-
m-relay
<jeffro256:monero.social> Oh wasn't the default upload/download byte limits tweaked recently?
-
m-relay
<ofrnxmr:xmr.mx> Yeah, 32768down and 8192up
-
m-relay
<ofrnxmr:xmr.mx> My avg is only 1.48MB/s down though
-
selsta
.merge+ 9839
-
xmr-pr
Added
-
selsta
^ fixes CI