I think I can reproduce the problem now. See below.
On Tue, Sep 22, 2020 at 02:09:01PM -0400, Mark Johnston wrote:
! On Tue, Sep 22, 2020 at 07:31:07PM +0200, Peter wrote:
! > There is something, and I don't know who owns that:
! > $ vmstat -m | grep shmfd
! > shmfd 13 14K - 473 64,256,1024,8192
! >
! > But that doesn't look big either.
!
! That is just the amount of kernel memory used to track a set of objects,
! not the actual object sizes. Unfortunately, in 11 I don't think
there's
! any way to enumerate them other than running kgdb and examining the
! shm_dictionary hash table.
One of the owners of this is also postgres (maybe among others).
! I think I see a possible problem in i915, though I'm not sure if you'd
! trigger it just by using vt(4). It should be fixed in later FreeBSD
! versions, but is still a problem in 11. Here's a (untested) patch:
Thank You, I'll keep that one in store, just in case.
But now I found something simpler, while tracking error messages that
came into my glance alongside:
When patching to 11.4-p3, I had been reluctant to recompile lib32 and
install that everywhere, and had kicked it off the systems.
And obviousely, I had missed to recompile some of my old self-written
binaries and they were still i386 and were called by various scripts.
So what happens then is this:
$ file scc.e
scc.e: ELF 32-bit LSB executable, Intel 80386, version 1
(FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1,
for FreeBSD 9.3 (903504), stripped
$ ./scc.e
ELF interpreter /libexec/ld-elf.so.1 not found, error 8
Abort trap
And this will cost about some (hundred?) kB of swapspace every time it
happens. And they do not go away again, neither can the concerned jail
do fully die again.
So, maybe, when removing the lib32 & friends from the system, one
must also remove the "options COMPAT_FREEBSD32" from the kernel, so
that it might not try to run that binary, and maybe that would avoid
the issue. (But then, what if one uses lib32 only in *some* jails?
Some evil user in another jail can then bring along an i386 binary
and crash the system by bloating the mem.)
Anyway, my problem is now solved; as I needed these binaries back in
working order anyway.
regards,
PMc