<g​fdshygti53:monero.social> getmonero.org cert expired, who to contact for that?

<1​23bob123:matrix.org> Certbot renew —dry run

<b​az:monero.social> the cert isn't Let’s Encrypt... they aren't a traditional certificate authority

<b​az:monero.social> issued by: Organization: Cloudflare, Inc.

<1​23bob123:matrix.org> Sectigo

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.

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 ...

top will show memory usage. You want SHR.

VIRT: 194g, RES: 2.1g, SHR: 1.0g

just a gig

Oh wait. VIRT is the virtual address space, which is what mmaped data will be assigned to. SHR is shared libs etc. Sorry.

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.

no you're correct moneromooo

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

1.0G SHR, 2.1G RES means monerod itself is using 1.1G for whatever variables/state it maintains

SHR includes shared libs *and* the LMDB space because LMDB uses a shared mmap.

Ah, thanks.

and this is with release, self-compiled

so, memleak is unlikely

so when monerod is paired with xmrblocks and xmrblocks is heavily used, monerod will use a lot

and i guess systemd is tracking shared memory for some reason. i wonder if systemd has more specific memory accounting configs

unlikely. systemd is not exactly a model of good software design.

because it doesn't start at 37g. It starts low, and over a period of ~24 hours gets to this level

right, the more random blockchain queries you get, the more DB must be read into RAM

you should just disable those accounting controls. the shared memory usage doesn't impact system performance.

sometimes xmrchain.net feels sluggish (when you use the website). Then I restart the daemons and its snappy again

ah, make sure /proc/sys/vm/swappiness is zero

otherwise the kernel will prioritize FS cache over program memory, which is not helpful.

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

thanks hyc

<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

<1​23bob123:matrix.org> Check github

<1​23bob123:matrix.org> There was an update

<1​23bob123:matrix.org> monero-project/meta #923

<a​ck-j:matrix.org> Thank you, didnt know about that issue

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"

This might be new, as I did not find any issue for that; code is latest master