Привязанное монтирование исчезает после перезагрузки
Привязанное монтирование, сделанное командой, живёт до перезагрузки. Чтобы оно восстанавливалось, нужна запись в fstab или собственный mount-unit — иначе служба после перезагрузки увидит пустой каталог.
Вероятные причины
По порядку: сверху то, что встречается чаще.
-
Монтирование сделано только командой
Команда не сохраняет состояние. После перезагрузки каталог пуст, а служба об этом не знает.
-
Служба не объявила зависимость от монтирования
Даже с записью в fstab служба может стартовать раньше монтирования.
-
Данные записаны в точку монтирования до монтирования
Если служба успела записать файлы в пустой каталог, после монтирования они окажутся скрыты. Выглядит как потеря данных.
Диагностика
Команды идут в том порядке, в котором их стоит выполнять: каждая следующая проверяет то, что осталось после предыдущей.
Текущие привязанные монтирования.
findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS | grep -i bindЗаписи, которые восстановятся после перезагрузки.
grep -i bind /etc/fstabРешение
Решение своё для каждой причины. Сначала определите, какая из них ваша, — иначе правки наложатся друг на друга.
- Почему происходит
- Команда не сохраняет состояние. После перезагрузки каталог пуст, а служба об этом не знает.
- Как проверить
-
Посмотрите текущие привязки и записи.
findmnt -t none -o TARGET,SOURCE,OPTIONS | head grep -i bind /etc/fstab
- Как исправить
-
Добавьте запись в fstab с параметром привязки или создайте mount-unit. Второе удобнее, когда нужны зависимости.
# /etc/fstab # /srv/data /var/lib/myapp/data none bind,nofail 0 0
- Почему происходит
- Даже с записью в fstab служба может стартовать раньше монтирования.
- Как проверить
-
Посмотрите зависимость.
systemctl show myapp.service -p RequiresMountsFor
- Как исправить
-
Добавьте
RequiresMountsFor=с путём: systemd сам выстроит порядок.
- Почему происходит
- Если служба успела записать файлы в пустой каталог, после монтирования они окажутся скрыты. Выглядит как потеря данных.
- Как проверить
-
Посмотрите, нет ли скрытых файлов под точкой монтирования.
sudo mkdir -p /tmp/chk && sudo mount --bind / /tmp/chk && sudo ls /tmp/chk/var/lib/myapp/data | head; sudo umount /tmp/chk
- Как исправить
- Проверяйте пустоту точки монтирования и объявляйте зависимости: скрытые данные обнаруживаются в самый неудобный момент.
Пример вывода
Привязка исчезла после перезагрузки. Пример показательный: он собран на тестовой машине специально для этой страницы, а не взят из чужого журнала.
$ findmnt /var/lib/myapp/data
# пусто
$ grep -c bind /etc/fstab
0
myapp[1200]: warn: data directory is empty, starting from scratch
Связанные ошибки
- Имя mount-unit не соответствует точке монтирования systemd отказывается загружать .mount: имя файла должно быть получено из пути через systemd-escape. Как назвать unit правильно.
- Mount process exited, code=exited, status=32: не найдено устройство Монтирование не проходит: устройство или UUID не найдены, неверная файловая система, недоступен сетевой ресурс. Код 32 от команды mount.
- Правка fstab не применяется: генераторы unit Точки монтирования из fstab превращаются в unit генератором. Почему после правки нужен daemon-reload.
- Automount: каталог монтируется не вовремя или отваливается Автомонтирование через .automount: как работает TimeoutIdleSec, почему ресурс отваливается и когда лучше обычный .mount.
- Dependency failed for … и результат 'dependency' Сообщение Dependency failed for: служба не запускалась, потому что упала её зависимость. Как найти настоящего виновника.
- Device or resource busy при операции с файлом Ошибка 16: файл или устройство заняты. Разбор для точек монтирования, устройств и файлов конфигурации.
- MongoDB: Unable to lock file mongod.lock mongod не запускается: остался файл блокировки после аварийного завершения или каталог принадлежит не тому пользователю.
- MySQL: InnoDB не запускается после аварийного завершения Ошибки InnoDB при старте: повреждение страниц, несовпадение журнала, режим принудительного восстановления.
Источники
-
systemd.mount(5)
Привязанные монтирования и параметры. -
Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
Воспроизведено привязкой, сделанной командой, с последующей перезагрузкой.