On Tue, 4 Feb 2020 at 17:29, Tim Woodall via GLLUG <gllug@mailman.lug.org.uk> wrote: > > Hi, > > Last night radvd got killed by the oom killer > Feb 4 02:32:11 firewall17 vmunix: [1762825.239631] [ pid ] uid tgid > total_vm rss pgtables_bytes swapents oom_score_adj name > Feb 4 02:32:11 firewall17 vmunix: [1762825.239671] [ 3882] 105 3882 > 68490 19387 581632 48648 0 radvd > > When I look on another host I see that it's rather larger than I would > have expected: > 3247 radvd 20 0 177228 41016 556 S 0.0 24.0 16:07.26 radvd > > After a bounce it looks better: > 1030 radvd 20 0 2444 1616 1476 S 0.0 0.9 0:00.01 radvd > > > I cannot find anything about radvd having memory leaks. Does anyone know > if this large memory footprint is expected (I'm running it on a VM with > not much memory and I can increase that if necessary)? > > I can obviously restart it to avoid this issue. I wonder if it could be > related to VPN interfaces that are constantly being created and removed. >
Well its open source, so in theory you could diagnose the leak yourself. clang has a very useful "-fsanitize=address" option. It allows the program to run pretty much at full speed, and then reports memory leaks. -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug