On 2021-06-25 07:41, Michael Gmelin wrote:
It seems like non-anonymous POSIX shared memory is not freed automatically when a jail is removed and keeps it in a dying state, until the shared memory segment is deleted manually.See below for the most basic example: [root@jailhost ~]# jail -c path=/ command=/bin/sh # posixshmcontrol create /removeme # exit [root@jailhost ~]# jls -dv -j shmtest dying true So at this point, the jail is stuck in a dying state. Checking POSIX shared memory segments shows the shared memory segment which is stopping the jail from crossing the Styx: [root@jailhost ~]# posixshmcontrol list MODE OWNER GROUP SIZE PATH rw------- root wheel 0 /removeme After removing the shared memory segment manually... [root@jailhost ~]# posixshmcontrol rm /removeme the jail passes away peacefully: [root@jailhost ~]# jls -dv -j shmtest dying jls: jail "shmtest" not found I wonder if it wouldn't make sense to always remove POSIX shared memory created by a jail automatically when it's removed.
That does seem reasonable, though it would take some bookkeeping to do right. There is currently no concrete idea of a jail's ownership of a POSIX shm object, as it uses only uid and gid for access permissions, same as files. The tie to the jail is in the underlying vm_object, which holds a cred that references the jail - that seems to be what's keeping the jail from going away. Like files, POSIX shared memory is one way a jail may communicate with the rest of the system. So it's theoretically conceivable that shared memory created by a defunct jail my still be in use by a parent jail, in the same way that shared memory created by a defunct process is still visible to other processes, but that may be a rare enough case to disregard. - Jamie
