damn. xmrchain node got killed again. im running gdb, but it says the program no longer exists. i think its getting oom killed but i don't know why

i guess i can run it with the tagged release and see if it still happens

<o​frnxmr:xmr.mx> How much resources is that node using

<g​ingeropolous:monero.social> currently using 25G of ram

<g​ingeropolous:monero.social> im gonna limit the number of peers. i had inc at unlimited and outgoing at 126

<g​ingeropolous:monero.social> hrm, trying to add block message to testnet blocks to test forking behavior, getting this "Failed to load data from /miner_conf.json" buwut

<o​frnxmr:xmr.mx> Bro u dont need > 32 outgoing

<s​yntheticbird:monero.social> I need it as im building a super node thx for worrying tho

<o​frnxmr:xmr.mx> And dont really need > 100 in either

<o​frnxmr:xmr.mx> Unlimited peers is probably what killed it monero-project/monero #9334

<t​zadiko:matrix.org> monero-project/monero #9875

<s​yntheticbird:monero.social> oh my good Tzadiko stop cooking! 🔥🔥🔥

praise good

<t​obtoht:monero.social> tzadiko: please force-push changes to prs instead of adding commits. non-squashed prs are less likely to get reviews and will not be merged as-is. if you have a gpg key, please sign your commits. if your pr is still a wip, convert it to a draft.

having unlimited incoming peers is default and should not be an issue. >32 out is excessive but also should not cause issues

<t​zadiko:matrix.org> Ok, thanks. This workflow is new to me.

<t​obtoht:monero.social> np, if you have questions feel free to ask here or dm me anytime

<o​frnxmr:xmr.mx> <s​elsta> having unlimited incoming peers is default and should not be an issue. >32 out is excessive but also should not cause issues << its (iirc) unlimited to prevent privacy issues from sybils, but definitely causes huge increases in resources

<o​frnxmr:xmr.mx> Btc and other chains default to ~115 max incoming and, iirc, 8 or 12 out

<t​obtoht:monero.social> tag still on for today?

<o​frnxmr:xmr.mx> I'm falling asleep

i run all my nodes with unlimited incoming peers and no resource issues

we can tag today but i feel there are multiple issues remaining (ginger having issues with blockchain explorer, offn having chain sync freeze multiple times)

selsta, yeah but are your nodes the target of skiddies

but maybe we just have to tag at some point

<s​yntheticbird:monero.social> it's enough, we need to tag

<s​yntheticbird:monero.social> Frankly, this is embarrassing that a release is delayed again and again and again because of unidentified bug. There is at least one vuln in the wild right now, the current branch is capable of syncing and is pretty much stable for everyone. We need to tag or otherwise we're slowly turning into a grub2 situation

<s​yntheticbird:monero.social> delaying is giving no benefit at this point because of how large the difference is between 18.3.4 and 18.4.0

<s​yntheticbird:monero.social> waiting have no benefits

<r​4v3r23:monero.social> chill, that means theyll just tag 18.4 knowing full well 18.4.1 is incoming right away

<s​yntheticbird:monero.social> yeah i would like too hope in two weeks, but the reality is that 18.4.1 could come in another 3 months

<r​4v3r23:monero.social> no reason to knowingly schedule 2 back to back releases

<s​yntheticbird:monero.social> you don't know its going to be back to back

<s​yntheticbird:monero.social> right now we're taking a month to correct a bug on the TODO list

<s​yntheticbird:monero.social> so with gingerpolous and ofrnxmr having bug we haven't even identified i don't expect this to be fixed in weeks

<r​4v3r23:monero.social> you dont know thats not. if you leave identified bugs open then you need another release sooner rather than later

<r​4v3r23:monero.social> and if a point release IS months away, best to make 18.4 as stable as possible

<s​yntheticbird:monero.social> Hard disagree, a release should be delayed because another one is coming a month after, really it's some grub2 tier scheduling here.

<s​yntheticbird:monero.social> a month is long

<r​4v3r23:monero.social> wut

<s​yntheticbird:monero.social> 18.4.0 should have been released back in 2024

<r​4v3r23:monero.social> just build the release branch? you dont need cores permission

<r​4v3r23:monero.social> its not a hard fork release

<s​yntheticbird:monero.social> lmao

<s​yntheticbird:monero.social> you know well 99% of people aren't updating unless we told them to do so, and they need to update

<r​4v3r23:monero.social> 99% of people arent complaining here

<r​4v3r23:monero.social> its literally just you

<r​4v3r23:monero.social> so run the branch and chill

<r​4v3r23:monero.social> this was directed at YOU

<s​yntheticbird:monero.social> you are misinformed

<r​4v3r23:monero.social> cool

<r​4v3r23:monero.social> because we arent on your schedule lmao

<r​4v3r23:monero.social> have a good day

<s​yntheticbird:monero.social> whatever, agree to disagree

yeah, since the fix is not identified, and there's an exploit in the wild, yes should ship asap

<o​frnxmr:xmr.mx> Tbf, i have not tested to see if my bug hits on 18.3.4

there's no telling when the fix will be idenfied & merged. should ship asap

<o​frnxmr:xmr.mx> he exploit only effects _public_ rpc node

<o​frnxmr:xmr.mx> Most of which are already running the fix

having a major release that freezes or crashes is worse than a RPC vulnerability in my opinion since it can also possibly impacts p2p nodes

<t​obtoht:monero.social> gingeropolous: is this the same box that was thought to have potential hardware issues? or was that ruled out

either way with such a large release we will have a .1 follow up so I will ask luigi to tag

<o​frnxmr:xmr.mx> Ginger and i have different issues. Both of which coukd be hardware related, and reproducing isnt easy. For mine, i have to (and have) resynced the chain like 30x, and hit the bug probably 10+% of the time.

<o​frnxmr:xmr.mx> I think gingers node is being killed from same issue that caused selstas OOM - tx propagation

<o​frnxmr:xmr.mx> Ginger having over 1 thousand connections (iirc) means he's one of very few nodes with that many

<o​frnxmr:xmr.mx> Most others usually top out at 100-300 (i think)

tx propagation causing OOM is only relevant if there is a huge txpool backlog

<o​frnxmr:xmr.mx> Isnt it simple a product of txpool size * connections

<o​frnxmr:xmr.mx> So 10mb * 100 connections == 1mb * 1000 connections (forgive me)

only outgoing connections are relevant from what I remember

luigi1111: you can tag whenever you have time

<b​oog900:monero.social> outgoing connections have a longer queue timer (on average), but inbound connections still have the queue.

<b​oog900:monero.social> longer queue timer = more time to build up txs in it

(v0.18.4.0) also please ping me once done so I can update gui

K

<s​yntheticbird:monero.social> luigi-chad.gif

<o​frnxmr:xmr.mx> If only luigi1111 could see that