Как lsof -p $pid может зависать, если ls /proc/$pid/fd нет?

Эта часть справочной страницы вводит в заблуждение. Как правило, вам нужен другой порядок, как описано в man 8 pivot_root.

cd new_root             # chdir(new_root);
pivot_root. put_old    # pivot_root(".", put_old);
exec chroot.           # chroot(".");

Это, кажется, еще одна тонкая деталь с pivot_root. Хотя смысл pivot_rootсостоит в том, чтобы изменить пространство имен монтирования, код ядра , по-видимому, говорит, что корневая файловая система, которую он перемещает, определяется корнем каждого -процесса, а это то, что chrootнаборы.

В результате мы сталкиваемся с ошибкой «новый _корень или поместите _старый в текущую корневую файловую систему».

Эта тонкая деталь pivot_rootнеобходима для того, чтобы он работал вообще на современном Linux. Если бы он был определен для работы с корневым монтированием пространства имен монтирования, он попытался бы переместить специальную rootfsфайловую систему, которую вы обычно не видите . Но это не разрешено, потому что rootfs всегда должен быть корневым монтированием пространства имен .


Мы можем подтвердить, что pivot_rootработает таким образом, продолжив пример следующим образом.

# unshare -m
# mount --bind / /mnt
# cd /mnt
# chroot /mnt
# pivot_root. mnt
pivot_root: failed to change root from `.' to `mnt': Device or resource busy

# exit  # leave chroot
# mount --bind. mnt
# cd mnt
# mount --bind /proc proc
# findmnt | grep mnt
└─/mnt                                /dev/mapper/alan_dell_2016-fedora ext4            rw,relatime,seclabel
  └─/mnt                              /dev/mapper/alan_dell_2016-fedora ext4            rw,relatime,seclabel
    └─/mnt/proc                       proc                              proc            rw,nosuid,nodev,noexec,relatime

# chroot /mnt  # re-enter chroot
# cd /mnt
# pivot_root. mnt  # this one works
# exit  # leave chroot
# findmnt | grep mnt
└─/mnt                                /dev/mapper/alan_dell_2016-fedora        ext4            rw,relatime,seclabel
  ├─/mnt/mnt                          /dev/mapper/alan_dell_2016-fedora        ext4            rw,relatime,seclabel
  └─/mnt/proc                         /dev/mapper/alan_dell_2016-fedora[/proc] ext4            rw,relatime,seclabel

Второй вызов pivot_rootработает. Но это никак не повлияло на корень пространства имен монтирования. Глядя снаружи на chroot, он поменял местами /mntи /mnt/mnt.

0
06.08.2020, 21:52
1 ответ

В конце концов, это выглядело как «осиротевшие» файлы, по-видимому, связанные с монтированием NFS в контейнеры в то время, когда сервер NFS был недоступен. После того, как я идентифицировал и удалил эти(e4defragи )lsof, они больше не зависали, т.е. снова вели себя так, как ожидалось.

0
18.03.2021, 23:14

Теги

Похожие вопросы