01:03:14 <m-relay> <j​effro256:monero.social> Yes this is the issue, working on a fix
02:11:11 <selsta> tzadiko: please open a github issue if you think you found a bug so that it does not get lost
02:11:40 <m-relay> <t​zadiko: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
02:15:05 <m-relay> <s​yntheticbird: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).
02:16:04 <m-relay> <t​zadiko: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.
02:16:44 <m-relay> <o​frnxmr:xmr.mx> still a good idea to open it as an issue, as it can be a place for discussion about the specific problem
02:19:26 <selsta> I'm unsure currently about 9838, we usually don't approve rewrite PRs
02:20:29 <selsta> a simple PR that just fixes a bug will be easier to get approved
03:25:49 <m-relay> <t​zadiko:matrix.org> Ok
03:31:19 <m-relay> <t​zadiko:matrix.org> https://github.com/monero-project/monero/issues/9841
03:55:37 <m-relay> <t​zadiko:matrix.org> Accompanying MR: https://github.com/monero-project/monero/pull/9842
07:02:16 <m-relay> <m​axxor:nitro.chat> hello everyone :)
07:07:06 <m-relay> <m​axxor: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?
13:59:30 <m-relay> <b​oog900:monero.social> Yes
14:16:59 <m-relay> <j​effro256:monero.social> Working on a fix here: https://github.com/monero-project/monero/pull/9844
14:27:12 <m-relay> <j​effro256:monero.social> Also, looks like there is problems with the Arch Linux build in the Trezor code: https://github.com/monero-project/monero/actions/runs/13901687577/job/38894790640?pr=9844
14:35:48 <m-relay> <o​frnxmr:monero.social> I'm testing now. Deleted blockchain so resyncing
14:37:34 <m-relay> <j​effro256:monero.social> You can also restart from where it gets stuck and sync from there. Works for me
14:37:44 <m-relay> <j​effro256:monero.social> But yes, 0 to present syncing tests is also a good idea
14:37:57 <m-relay> <m​onero.arbo:matrix.org> https://github.com/tobtoht/monero/commit/a5fabe5134026f04f3a77e82253c00a2d4baf0fa
14:41:17 <m-relay> <o​frnxmr:xmr.mx> Yeah, i mean, i deleted the blockchain like 5mins before i saw your pr :P
16:04:39 <m-relay> <o​frnxmr:xmr.mx> jeffro256  just passed the height
16:05:53 <m-relay> <o​frnxmr:xmr.mx> First 1.8m blocks in 1hr35min
16:16:08 <gingeropolous> damn, xmrchain.net node went down.
16:16:44 <gingeropolous> "Program terminated with signal SIGKILL, Killed." ... gdb says program no longer exists. I wonder if it got oom killed
16:27:39 <Guest99> ola
16:46:11 <m-relay> <o​frnxmr:xmr.mx> `2025-03-17 16:44:51.412 E Couldn't start RandomX seed thread                Couldn't start RandomX seed thread`
16:46:12 <m-relay> <o​frnxmr: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)
16:46:20 <m-relay> <o​frnxmr:xmr.mx> It synced np the other day
16:46:50 <m-relay> <j​effro256:monero.social> Hmmmmm I don't know what the immediate cause would be..
16:47:03 <m-relay> <j​effro256:monero.social> Do you have enough available RAM?
16:47:18 <m-relay> <j​effro256:monero.social> It will allocate ~ 256 MB
16:47:30 <m-relay> <o​frnxmr:xmr.mx> Yeah, over 10gb free
16:48:37 <m-relay> <o​frnxmr: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
16:49:31 <m-relay> <o​frnxmr:xmr.mx> Oh, i also set --prep-blocks-threads=8
16:57:16 <sech1> that error only happens when pthread_create() function fails. Maybe check if you hit the open files limit (ulimit -n)?
16:59:30 <dukenukem> -12
16:59:52 <sech1> or ulimit -r
17:03:31 <m-relay> <j​effro256:monero.social> I thought it was `ulimit -u` ?
17:03:51 <m-relay> <j​effro256:monero.social> There's also `cat /proc/sys/kernel/threads-max`
17:04:25 <m-relay> <j​effro256:monero.social> `n` is for file descriptors, `r` is for scheduling priority IIUC
18:06:41 <m-relay> <t​zadiko: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?
18:06:57 <m-relay> <t​zadiko:matrix.org> By 'fail on the build' I mean on Github.
18:12:22 <m-relay> <j​effro256:monero.social> That test fails sporadically, especially when the system has bad entropy
21:09:52 <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
21:10:52 <ofrnxmr> Was 21+hrs on prior runs.. not sure why so fast this time
21:19:25 <m-relay> <j​effro256:monero.social> `--sync-pruned-blocks` should drop the majority of your bandwidth when in the checkpointed zone
21:24:10 <m-relay> <o​frnxmr:xmr.mx> Network bandwidth isnt the issue
21:24:37 <m-relay> <o​frnxmr:xmr.mx> I'm always downloaded well ahead (gbs) of the current blocks being synced
21:25:35 <m-relay> <o​frnxmr:xmr.mx> https://matrix.monero.social/_matrix/media/v1/download/xmr.mx/ADtaUvkAHMdhbBTnbFaFISRx
21:25:42 <m-relay> <o​frnxmr:xmr.mx> Example from the other day
21:27:15 <m-relay> <j​effro256:monero.social> Oh wasn't the default upload/download byte limits tweaked recently?
21:33:59 <m-relay> <o​frnxmr:xmr.mx> Yeah, 32768down and 8192up
21:37:42 <m-relay> <o​frnxmr:xmr.mx> My avg is only 1.48MB/s down though
22:18:39 <selsta> .merge+ 9839
22:18:39 <xmr-pr> Added
22:19:32 <selsta> ^ fixes CI