Предотвращение доступа SIGINT к подпроцессу mysql.

EDIT1 After stopping systemd-logind - which native Xorg responds to by dying - and restarting Xorg, I see the entire 6GB of swap wiped out.

После второго раза я могу подтвердить, что это ошибка в systemd -logind. logindне забывает закрыть копию DRM fd, которая хранится в нем, но не может закрыть копию, хранящуюся в PID1 (используется поддержка «бесшовного» перезапуска logind):

$ sudo lsof /dev/dri/card0 | grep systemd
[sudo] password for alan-sysop: 
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
      Output information may be incomplete.
systemd      1       root   16u   CHR  226,0      0t0 14690 /dev/dri/card0
systemd      1       root   87u   CHR  226,0      0t0 14690 /dev/dri/card0
systemd      1       root  101u   CHR  226,0      0t0 14690 /dev/dri/card0
systemd      1       root  106u   CHR  226,0      0t0 14690 /dev/dri/card0
systemd      1       root  110u   CHR  226,0      0t0 14690 /dev/dri/card0
systemd-l  860       root   21u   CHR  226,0      0t0 14690 /dev/dri/card0
systemd-l  860       root   25u   CHR  226,0      0t0 14690 /dev/dri/card0

Это очень похоже на известную ошибку, которая уже должна быть исправлена ​​в версии 238 systemd .

---

Похоже, что logind пропускает DRM fd таким образом каждый раз, когда я вхожу в GNOME и выхожу из него. Предположительно, эта ошибка становится очевидной только тогда, когда у вас некорректно отключаются серверы отображения, поэтому у них нет возможности освободить буферы, прикрепленные к их DRM fd.

EDIT2: Am I right to guess that a file descriptor of a graphics device (DRM), can hold a reference to swappable memory? Note logind holds such file descriptors.

Ответ :да.

filp

SHMEM file node used as backing storage for swappable buffer objects.

--https://www.kernel.org/doc/html/v4.15/gpu/drm-mm.html

Насколько я понимаю, "файловый узел SHMEM" здесь - это то, что выполняет ту же работу, что и файл tmpfs/memfd. Вышеприведенная цитата касается «буферного объекта GEM»…

The mmap system call can't be used directly to map GEM objects, as they don't have their own file handle. Two alternative methods currently co-exist to map GEM objects to userspace... The second method uses the mmap system call on the DRM file handle.

--https://01.org/linuxgraphics/gfx-docs/drm/drm-memory-management.html#id-1.3.4.6.6.8

ЗАКЛЮЧЕНИЕ:кто-то должен дважды -проверить текущий код в logind, так как он относится к закрытию дескрипторов файлов :).

---

Приложение :, как можно попытаться исключить memfds

Does anyone have a nice way to check memory usage of memfds?

Использование памяти memfds можно прочитать с помощью stat --dereferenceили du -Dпо волшебной символической ссылке в /proc/$PID. Либо под fd/$FDдля файлового дескриптора, либо -, который вы забыли-map_files/...для памяти -отображаемых объектов.

У меня нет очень удобного для этого удобства, но вы можете, по крайней мере, искать самые большие отдельные FD или сопоставленные файлы. (Приведенный ниже пример не является дополнительным доказательством; это было сделано после того, как 6 ГБ подкачки исчезли ).

$ sudo du -aLh /proc/*/map_files/ /proc/*/fd/ | sort -h | tail -n 10
du: cannot access '/proc/self/fd/3': No such file or directory
du: cannot access '/proc/thread-self/fd/3': No such file or directory
108M    /proc/10397/map_files/7f1e141b4000-7f1e1ad84000
111M    /proc/14862/map_files/
112M    /proc/10397/map_files/
113M    /proc/18324/map_files/7efdda2fb000-7efddaafb000
121M    /proc/18324/map_files/7efdea2fb000-7efdeaafb000
129M    /proc/18324/map_files/7efdc82fb000-7efdc8afb000
129M    /proc/18324/map_files/7efdd42fb000-7efdd4afb000
129M    /proc/18324/map_files/7efde52fb000-7efde5afb000
221M    /proc/26350/map_files/
3.9G    /proc/18324/map_files/

$ ps -x -q 18324
  PID TTY      STAT   TIME COMMAND
18324 pts/1    S+     0:00 journalctl -b -f

$ ps -x -q 26350
  PID TTY      STAT   TIME COMMAND
26350 ?        Sl     4:35 /usr/lib64/firefox/firefox

$ sudo ls -l /proc/18324/map_files/7efde52fb000-7efde5afb000
lr--------. 1 root root 64 Mar 19 00:32 /proc/18324/map_files/7efde52fb000-7efde5afb000
-> /var/log/journal/f211872a957d411a9315fd911006ef03/user-1001@c3f024d4b01f4531b9b69e0876e42af8-00000000002e2acf-00055bbea4d9059d.journal