Hi Todd! You're right, the number of mbufs on the machine in question is steadily climbing.
This is a few minutes after a reboot, with an RC script starting wireguard automatically: > 27836 mbufs in use: > 27827 mbufs allocated to data > 3 mbufs allocated to packet headers > 6 mbufs allocated to socket names and addresses > 0/16 mbuf 2048 byte clusters in use (current/peak) > 20/75 mbuf 2112 byte clusters in use (current/peak) > 0/8 mbuf 4096 byte clusters in use (current/peak) > 0/0 mbuf 8192 byte clusters in use (current/peak) > 0/0 mbuf 9216 byte clusters in use (current/peak) > 0/0 mbuf 12288 byte clusters in use (current/peak) > 0/0 mbuf 16384 byte clusters in use (current/peak) > 0/0 mbuf 65536 byte clusters in use (current/peak) > 7192/7192/524288 Kbytes allocated to network (current/peak/max) > 0 requests for memory denied > 0 requests for memory delayed > 0 calls to protocol drain routines And then, just a second or two later: > 27874 mbufs in use: > 27863 mbufs allocated to data > 5 mbufs allocated to packet headers > 6 mbufs allocated to socket names and addresses > 0/16 mbuf 2048 byte clusters in use (current/peak) > 20/75 mbuf 2112 byte clusters in use (current/peak) > 0/8 mbuf 4096 byte clusters in use (current/peak) > 0/0 mbuf 8192 byte clusters in use (current/peak) > 0/0 mbuf 9216 byte clusters in use (current/peak) > 0/0 mbuf 12288 byte clusters in use (current/peak) > 0/0 mbuf 16384 byte clusters in use (current/peak) > 0/0 mbuf 65536 byte clusters in use (current/peak) > 7204/7204/524288 Kbytes allocated to network (current/peak/max) > 0 requests for memory denied > 0 requests for memory delayed > 0 calls to protocol drain routines >From the nearly identical Pi (sans wireguard): > 72 mbufs in use: > 42 mbufs allocated to data > 1 mbuf allocated to packet headers > 29 mbufs allocated to socket names and addresses > 12/64 mbuf 2048 byte clusters in use (current/peak) > 0/0 mbuf 2112 byte clusters in use (current/peak) > 0/8 mbuf 4096 byte clusters in use (current/peak) > 0/0 mbuf 8192 byte clusters in use (current/peak) > 0/0 mbuf 9216 byte clusters in use (current/peak) > 0/0 mbuf 12288 byte clusters in use (current/peak) > 0/0 mbuf 16384 byte clusters in use (current/peak) > 0/0 mbuf 65536 byte clusters in use (current/peak) > 216/216/131072 Kbytes allocated to network (current/peak/max) > 0 requests for memory denied > 0 requests for memory delayed > 0 calls to protocol drain routines I tried disabling the wg startup. When I start the box I have very few mbufs (around 50) like on the other machine. Once I start wireguard manually it begins climbing again, though the number is nowhere near the "27836 mbufs in use" like when it loads at boot. When I stop wireguard (with wg-quick, destroying the interface), the number of mbufs stays where it is but stops climbing. What should I do next? --Matt > On Jul 30, 2021, at 9:31 AM, Todd C. Miller <todd.mil...@sudo.ws> wrote: > On Thu, 29 Jul 2021 20:09:12 -0500, "Matt P." wrote: > >> I have an OpenBSD box that breaks after a week or so of running. All network >> traffic stops reaching the box. If I look at the screen or serial output, I c >> an get the "login:" prompt, and when I enter my name I get prompted for a pas >> sword, but once I enter a password it hangs. Key presses and control codes st >> ill show on the screen, but the login never succeeds or fails. I thought cont >> rol-C might cause it to go back to the login prompt, but it doesn't. I have t >> o hard reboot the box to get it back. > > This may be due to a memory leak. You could monitor the output of > "netstat -m" and also "vmstat -m" and watch for memory use increasing > over time. The number of mbufs in use reported by "netstat -m" > should be relatively stable. > > - todd
