hm, it seems that with 0.17.1.7, my daemon runs out of memory and dies. FreeBSD/x64 with 4GB of RAM

didn't happen with 0.17.1.5, i think

it’s an attack

oh.

try compiling release-v0.17 or apply gui.xmr.pm/files/block_tor.txt

thanks, i'll update and rebuild

block_tor.txt is to be used separately/in addition to block.txt?

separate

thanks again

seem to found another, selsta

198.211.114.149

Kronovestan:

thanks

Snipa: please revert 7154 / 7155 if you have time, looks like it can cause issues

or luigi1111w

or wait, we can just patch it, no need to revert

I will let it run and hopefully that will fix it thank you!

how often should I update the ban list?

mnt_grrrl: minimum as often as you join and quit

just a random observation - I see ~700-800 reads/sec while syncing, catching up from 1 month offline

about 3.2MB/sec of read bandwidth

on NVME ssd

so that's the lookup cost to validate incoming blocks

at around 50 blocks/sec

this is without any disk writes because most of that is still cached

but this read reate is keeping my ssd 45% busy

when cache flushes and writes kick in, goes to 100% busy

oh nope this isn't NVME, this is my USB-attached SSD

hundreds of reads at around 2ms per read. I seem to recall my old HDD spec'd at 16ms per IOP

so, HDD would be 8-16x slower to sync

something weird going on with target height again paste.debian.net/1178471

moneromooo: seen that before? ^

Wonder if the fixes against the attacks are working. 5GB memory used so far and growing 100M a minute.

you're running with the patch for large network messages?

running the latest commit, b222188

i assume that has the patches :)

I guess that should, yeah

my other node, after the same patches, just spits out this

Unable to send transaction(s) to tor - no suitable outbound connections at height 2261195

maybe unrelated to the patches but didnt have it before

that's nothing unusual

ok. Maybe just didnt pay attention before

Strange. That node is doing fine memory-wise.

The other one now up to 5.5GBs

try tweaking the logs: set_log 0,net.cn:WARN

see if anything new shows up on either node

ok thx

also, how are you checking the process size?

my monerod here is using just under 2GB, but 1.7GB of that is shared memory, which is basically no cost

yeah im checking the res usage

subtract the shared usage

6GB res, 4GB shr

then doesn't look out of the ordinary

oh ok. Probably same there..didnt think to look at it before. But the other nodes are just like 600M/300M

anyway lets see. If it doesnt eat up it all and get killed it doesnt really matter how much it uses :)

this one probably jut has had more connections

or more connections to peers that needed more blocks to sync

if the process size keeps growing and shared memory use is shrinking, then that could indicate a problem

ok

Howard Chu is a high IQ scholar, he has more Google images with a violin than Sting with a guita, he singlehandely saved NASA from doom.

Why can't the saviour of NASA save Monero?

LOL easy to find the bad IP when you just log into his nodes and ASK THEM

selsta, can add 167.99.113.37 and 167.172.153.102 and 159.65.173.58

Kronovestan: done, thanks

added the first two, the last one was in the list already

Just trying to do my part and make a strong node. *flex*

.merges

Is there any reason it would be a bad idea to have a community-maintained Docker container/compose for bringing up a latest-release node with exposed p2p/restricted-RPC to let people run across OSs for public nodes?

With either building latest from source or downloading/verifying binaries (but leaning towards building frm source)

Add in a simple manager script and it should greatly simplify people running nodes across OSs without needing to maintain distinct guides per distro/OS/etc.

sethsimmons: hub.docker.com/r/xmrto/monero

Or that :)

updated 7207 to fix boost compatability

Did you mean to include the commit from 7193 in 7208 ?

yes, it is on top of 7193

it is already merged to master so I didn’t have to include it in master

Could somebody take a look at monero-project/monero-site #1327#discussion_r548321015? That phrasing sounds unclear to me as well (it's the guide to solo-mine with the gui)

s/cache/threads ?

that would make more sense

I really don't remember who wrote that guide (and git is not helping), if the author is around please clarify. Looks like a small thing but the guides have to be perfectly in sync before we adapt the new i18n system.

could it be with 7209 that once it hits the limit it prints refresh done?

it continues to refresh in the background, just a visual thing

It ought not to, unless it's failing thrice in a row. But in that case it would not succeed again if the portable storage limits were the reason as it restarts at full size.

You should see the reason for the failure in the log at log level 2.

I have lots of stdout log spam here so I did not notice that.

moneromooo irccloud.com/pastebin/Ea9Es8Bw

How many did it fetch ? Should be shortly before that.

Pulled blocks: blocks_start_height 55944, count 1000, height 56944, node height 2261542

That's unexpected. It switches to 500 here.

the next one is 500

Pulled blocks: blocks_start_height 56943, count 500, height 57443, node height 2261542

longer log irccloud.com/pastebin/EpoVj58U

selsta: just to confirm, it does seem that my OOM issue is gone after updating to latest release-0.17

in fact it seems to be having 0 issues even without any ban lists

release-v0.17 has some other issues that we still have to fix

make sure you use the latest version of release-v0.17 which has the revert

hm, ok, i'll update to that

on d3e582e51. anything specific i should watch or monitor to help test any of these changes?

the +2 thing will show up again as we had to revert the fix for now

otherwise wallet sync might not work

gotcha. i just got the +2 thing but it went back to normal a second later

.merges

moneromooo: it seems like 7188 is enough for the +2 attack to not happen currently