Следует ли отключать 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 (последние) со своими собственными сценариями.

  • Как монтировать контейнер Truecrypt с тайм-аутом из командной строки?
  • Определите процесс, который все еще использует файл в ленивой немонтированной файловой системе
  • Как разрешить, когда IP-адрес сервера NFS изменяется
  • Ужасная ситуация - файловые системы, смонтированные одновременно несколькими независимыми экземплярами ОС
  • Как я могу fsck раздел, когда устройство читает как занятое (но было подтверждено иначе)?
  • sshfs - не может размонтировать точку
  • umount внешний привод ntfs как не root
  • Командная строка эквивалентна «Безопасно удалить диск»?
  • 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 - лучшая ОС в мире.