02:25:41 <ndorf> hm, it seems that with 0.17.1.7, my daemon runs out of memory and dies. FreeBSD/x64 with 4GB of RAM
02:25:48 <ndorf> didn't happen with 0.17.1.5, i think
02:25:58 <selsta> it’s an attack
02:26:06 <ndorf> oh.
02:26:15 <selsta> try compiling release-v0.17 or apply https://gui.xmr.pm/files/block_tor.txt
02:26:28 <ndorf> thanks, i'll update and rebuild
02:26:43 <ndorf> block_tor.txt is to be used separately/in addition to block.txt?
02:27:07 <selsta> separate
02:27:28 <ndorf> thanks again
04:22:14 <Kronovestan> https://i.imgur.com/6JVQcep.png
04:22:21 <Kronovestan> seem to found another, selsta
04:22:34 <Kronovestan> 198.211.114.149
04:38:33 <selsta> Kronovestan:
04:38:35 <selsta> thanks
04:38:59 <selsta> Snipa: please revert 7154 / 7155 if you have time, looks like it can cause issues
04:39:27 <selsta> or luigi1111w
04:42:05 <selsta> or wait, we can just patch it, no need to revert
06:14:46 <mnt_grrrl> I will let it run and hopefully that will fix it thank you!
06:19:38 <mnt_grrrl> how often should I update the ban list?
07:18:56 <p0nziph0ne> mnt_grrrl: minimum as often as you join and quit
07:27:51 <hyc> just a random observation - I see ~700-800 reads/sec while syncing, catching up from 1 month offline
07:28:04 <hyc> about 3.2MB/sec of read bandwidth
07:28:10 <hyc> on NVME ssd
07:28:50 <hyc> so that's the lookup cost to validate incoming blocks
07:29:27 <hyc> at around 50 blocks/sec
07:30:04 <hyc> this is without any disk writes because most of that is still cached
07:30:46 <hyc> but this read reate is keeping my ssd 45% busy
07:31:04 <hyc> when cache flushes and writes kick in, goes to 100% busy
07:32:05 <hyc> oh nope this isn't NVME, this is my USB-attached SSD
07:34:19 <hyc> hundreds of reads at around 2ms per read. I seem to recall my old HDD spec'd at 16ms per IOP
07:34:35 <hyc> so, HDD would be 8-16x slower to sync
07:48:23 <hyc> something weird going on with target height again https://paste.debian.net/1178471/
07:50:05 <hyc> moneromooo: seen that before? ^
08:05:37 <zib> Wonder if the fixes against the attacks are working. 5GB memory used so far and growing 100M a minute.
08:06:08 <hyc> you're running with the patch for large network messages?
08:06:24 <zib> running the latest commit, b222188
08:06:33 <zib> i assume that has the patches :)
08:07:06 <hyc> I guess that should, yeah
08:07:32 <zib> my other node, after the same patches, just spits out this
08:07:34 <zib>  Unable to send transaction(s) to tor - no suitable outbound connections at height 2261195
08:07:43 <zib> maybe unrelated to the patches but didnt have it before
08:07:45 <hyc> that's nothing unusual
08:07:54 <zib> ok. Maybe just didnt pay attention before
08:08:45 <zib> Strange. That node is doing fine memory-wise.
08:08:52 <zib> The other one now up to 5.5GBs
08:10:14 <hyc> try tweaking the logs: set_log 0,net.cn:WARN
08:10:25 <hyc> see if anything new shows up on either node
08:10:40 <zib> ok thx
08:11:28 <hyc> also, how are you checking the process size?
08:13:03 <hyc> https://paste.debian.net/1178472/
08:13:38 <hyc> my monerod here is using just under 2GB, but 1.7GB of that is shared memory, which is basically no cost
08:13:50 <zib> yeah im checking the res usage
08:14:07 <hyc> subtract the shared usage
08:14:10 <zib> 6GB res, 4GB shr
08:14:21 <hyc> then doesn't look out of the ordinary
08:15:06 <zib> oh ok. Probably same there..didnt think to look at it before. But the other nodes are just like 600M/300M
08:15:23 <zib> anyway lets see. If it doesnt eat up it all and get killed it doesnt really matter how much it uses :)
08:15:26 <hyc> this one probably jut has had more connections
08:15:45 <hyc> or more connections to peers that needed more blocks to sync
08:16:59 <hyc> if the process size keeps growing and shared memory use is shrinking, then that could indicate a problem
08:17:21 <zib> ok
15:11:20 <Zhaij> 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.
15:11:20 <Zhaij> Why can't the saviour of NASA save Monero?
17:00:55 <Kronovestan> LOL easy to find the bad IP when you just log into his nodes and ASK THEM
17:07:57 <Kronovestan> selsta, can add 167.99.113.37 and 167.172.153.102 and 159.65.173.58
17:19:23 <selsta> Kronovestan: done, thanks
17:20:32 <selsta> added the first two, the last one was in the list already
17:22:14 <Kronovestan> Just trying to do my part and make a strong node. *flex*
18:26:32 <selsta> .merges
18:26:32 -xmr-pr- 7193 7196 7197
18:29:45 <sethsimmons> 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?
18:30:09 <sethsimmons> With either building latest from source or downloading/verifying binaries (but leaning towards building frm source)
18:30:45 <sethsimmons> 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.
18:32:13 <tobtoht> sethsimmons: https://hub.docker.com/r/xmrto/monero/
18:33:13 <sethsimmons> Or that :)
18:33:14 <selsta> updated 7207 to fix boost compatability
18:37:12 <iDunk> Did you mean to include the commit from 7193 in 7208 ?
18:38:14 <selsta> yes, it is on top of 7193
18:38:38 <selsta> it is already merged to master so I didn’t have to include it in master
18:51:08 <ErCiccione[m]> Could somebody take a look at https://github.com/monero-project/monero-site/pull/1327#discussion_r548321015? That phrasing sounds unclear to me as well (it's the guide to solo-mine with the gui)
18:53:29 <mfoolb> s/cache/threads ?
18:53:49 <ErCiccione[m]> that would make more sense
18:57:35 <ErCiccione[m]> 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.
19:32:38 <selsta> https://www.irccloud.com/pastebin/kpNj2X1I/
19:33:05 <selsta> could it be with 7209 that once it hits the limit it prints refresh done?
19:33:17 <selsta> it continues to refresh in the background, just a visual thing
19:37:09 <moneromooo> 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.
19:37:38 <moneromooo> You should see the reason for the failure in the log at log level 2.
19:38:24 <moneromooo> I have lots of stdout log spam here so I did not notice that.
19:52:47 <selsta> moneromooo https://www.irccloud.com/pastebin/Ea9Es8Bw/
19:54:27 <moneromooo> How many did it fetch ? Should be shortly before that.
19:54:56 <selsta> Pulled blocks: blocks_start_height 55944, count 1000, height 56944, node height 2261542
19:55:23 <moneromooo> That's unexpected. It switches to 500 here.
20:28:41 <selsta> the next one is 500
20:28:41 <selsta> Pulled blocks: blocks_start_height 56943, count 500, height 57443, node height 2261542
20:31:10 <selsta> longer log https://www.irccloud.com/pastebin/EpoVj58U/
21:39:06 <ndorf> selsta: just to confirm, it does seem that my OOM issue is gone after updating to latest release-0.17
21:39:28 <ndorf> in fact it seems to be having 0 issues even without any ban lists
21:39:44 <selsta> release-v0.17 has some other issues that we still have to fix
21:39:57 <selsta> make sure you use the latest version of release-v0.17 which has the revert
21:41:58 <ndorf> hm, ok, i'll update to that
21:46:12 <ndorf> on d3e582e51. anything specific i should watch or monitor to help test any of these changes?
21:46:33 <selsta> the +2 thing will show up again as we had to revert the fix for now
21:46:59 <selsta> otherwise wallet sync might not work
21:49:20 <ndorf> gotcha. i just got the +2 thing but it went back to normal a second later
22:00:09 <selsta> .merges
22:00:09 -xmr-pr- 7193 7196 7197
22:02:40 <selsta> moneromooo: it seems like 7188 is enough for the +2 attack to not happen currently