Следует ли отключать tmpfs при завершении работы системы?

Предположим, что у меня есть Linux-система с установленными ниже разделами (рядом с root):

  • proc on / proc
  • devtmpfs on / dev
  • devpts on / dev / pts
  • tmpfs on / dev / shm
  • sysfs on / sys
  • tmpfs on / var / run
  • tmpfs on / tmp

Что мне делать до остановки (самый последний скрипт выполнен, как раз перед выдачей команды halt)? Должен ли я обойти все эти файловые системы, оставив только / dev и / proc установленными? Может ли возникнуть проблема с этими файловыми системами? Есть ли лучшая практика в этом?

ОБНОВЛЕНИЕ: В настоящее время я использую sysvinit (последние) со своими собственными сценариями.

  • sshfs - не может размонтировать точку
  • Командная строка эквивалентна «Безопасно удалить диск»?
  • Установка и размонтирование в том же сценарии оболочки приводит к ошибке
  • Почему usb-drive не отображается с помощью `lsblk` после того, как он был удален из Thunar?
  • systemd: запуск сценария при завершении работы после того, как файловые системы установлены только для чтения
  • Безопасное удаление каталога только в том случае, если оно не является точкой монтирования
  • Umount сетевые диски с системойd перед выключением
  • Ужасная ситуация - файловые системы, смонтированные одновременно несколькими независимыми экземплярами ОС
  • One Solution collect form web for “Следует ли отключать tmpfs при завершении работы системы?”

    В Debian и, вероятно, его производных, скрипт, который обрабатывает размонтирование перед остановкой / перезагрузкой, – /etc/init.d/umountfs .

    Для меня сценарий не umount ни одной из файловых систем, которые вы указали отдельно от tmpfs . Причина приведена в следующем комментарии:

     # Make sure tmpfs file systems are umounted before turning off # swap, to avoid running out of memory if the tmpfs filesystems # use a lot of space. 

    Учитывая зрелость этих сценариев, я думаю, что это лучшая практика, хотя может быть хорошей идеей исследовать, что делают другие дистрибутивы.

    Также возможно, что команды halt / reboot действительно требуют, чтобы некоторые из вышеперечисленных монтировок работали (скорее всего, /proc , но также /sys и /dev ), и команда может выйти из строя без них.

    Обновить

    Чтобы добавить немного больше, следующий скрипт, который umountfs после umountfs , до фактического скрипта halt – это umountroot . Вопреки тому, что предлагает название, сценарий фактически перезагружает root readonly. Обратите внимание на фактический синтаксис для этого:

     mount $MOUNT_FORCE_OPT -n -o remount,ro -t dummytype dummydev / 2>/dev/null \ || mount $MOUNT_FORCE_OPT -n -o remount,ro dummydev / 2>/dev/null \ || mount $MOUNT_FORCE_OPT -n -o remount,ro / 

    Похоже, что просто выполняется прямое mount -no remount,ro / может выйти из строя, если есть другие точки монтирования, привязанные к корню. См. Эту ошибку для полного обсуждения этого. MOUNT_FORCE_OPT установлен только для FreeBSD, поэтому это не обязательно для Linux.

    Linux и Unix - лучшая ОС в мире.