01:36:04 <m-relay> <g​fdshygti53:monero.social> getmonero.org cert expired, who to contact for that?
02:10:06 <m-relay> <1​23bob123:matrix.org> Certbot renew —dry run
02:22:07 <m-relay> <b​az:monero.social> the cert isn't Let’s Encrypt... they aren't a traditional certificate authority
02:23:38 <m-relay> <b​az:monero.social> issued by: Organization: Cloudflare, Inc.
02:24:58 <m-relay> <1​23bob123:matrix.org> Sectigo
04:26:16 <gingeropolous> how do i tell if the mem thats used is shared or not? using "free -h" all i see is only 10 Gi used, 467Mi free, and 51Gi in buff/cache and available. 
07:22:51 <Inge> wait, if it is kernel file system cache, then it's probably in the buff/cache part? Not sure how that works for docker containers tho... now up to 1.74GB in use, but I have 16GB in buff/cache also available ...
08:00:33 <moneromooo> top will show memory usage. You want SHR.
08:03:06 <Inge> VIRT: 194g, RES: 2.1g, SHR: 1.0g 
08:03:14 <Inge> just a gig
08:08:40 <moneromooo> Oh wait. VIRT is the virtual address space, which is what mmaped data will be assigned to. SHR is shared libs etc. Sorry.
08:44:30 <euri10> greetings, just in case it's not been reported yet, but the website certificate expired, I just noticed it trying to get a tar in my docker image.
11:08:13 <hyc> no you're correct moneromooo
11:08:45 <hyc> virtual address space of 194G reflects the total size of the mmap for the blockchain, SHR shows how much of that is actually being used
11:09:11 <hyc> 1.0G SHR, 2.1G RES means monerod itself is using 1.1G for whatever variables/state it maintains
11:09:47 <hyc> SHR includes shared libs *and* the LMDB space because LMDB uses a shared mmap.
11:12:03 <moneromooo> Ah, thanks.
11:52:13 <gingeropolous> and this is with release, self-compiled
12:10:07 <hyc> so, memleak is unlikely
12:15:51 <gingeropolous> so when monerod is paired with xmrblocks and xmrblocks is heavily used, monerod will use a lot 
12:16:51 <gingeropolous> and i guess systemd is tracking shared memory for some reason. i wonder if systemd has more specific memory accounting configs
12:17:18 <hyc> unlikely. systemd is not exactly a model of good software design.
12:17:38 <gingeropolous> because it doesn't start at 37g. It starts low, and over a period of ~24 hours gets to this level
12:17:58 <hyc> right, the more random blockchain queries you get, the more DB must be read into RAM
12:18:56 <hyc> you should just disable those accounting controls. the shared memory usage doesn't impact system performance.
12:19:35 <gingeropolous> sometimes xmrchain.net feels sluggish (when you use the website). Then I restart the daemons and its snappy again
12:19:49 <hyc> ah, make sure /proc/sys/vm/swappiness is zero
12:20:07 <hyc> otherwise the kernel will prioritize FS cache over program memory, which is not helpful.
12:20:50 <xeno-machine> is my understanding of the monero idle sync protocol correct: for every connection, handshake and do a bunch of checks (is the payload data (peerlist) correct? is the network correct? is this a valid connection? etc), if we pass the checks update "just seen", otherwise close the connection
12:22:56 <gingeropolous> thanks hyc 
19:13:58 <m-relay> <a​ck-j:matrix.org> What is the status of the forensic investigation for the CCS wallet hack. Even though the funds were returned I’d like to have some certainty around how they were taken
19:14:18 <m-relay> <1​23bob123:matrix.org> Check github
19:14:27 <m-relay> <1​23bob123:matrix.org> There was an update
19:15:13 <m-relay> <1​23bob123:matrix.org> https://github.com/monero-project/meta/issues/923
19:19:38 <m-relay> <a​ck-j:matrix.org> Thank you, didnt know about that issue
21:06:11 <rbrunner> After I did `rescan_bc hard` on a working multisig wallet, it now complains the following when I try `export_multisig_info`: "Error: This multisig wallet is not yet finalized"
21:07:53 <rbrunner> This might be new, as I did not find any issue for that; code is latest master