NFS автомонтирование вызывает a stop job is running - задержку при выключении.

Hastra

New member
Сообщения
6
#1
Special Edition Смоленск 1.6.
В соответствии с https://wiki.astralinux.ru/pages/viewpage.action?pageId=27362314 используется Автоматическое монтирование ресурса при загрузке.
В случае, если происходит автомонтирование, затем отключается сервер, при выключении/перезагрузке компьютера возникает длительное зависание на a stop job is running до 1m 30s.
 

MickM

New member
Сообщения
211
#2
при выключении/перезагрузке компьютера возникает длительное зависание на a stop job is running до 1m 30s.
Вы контролируете выключение системы, а после физически отключаете электропитание?
+
Бытует мнение, что "Linux" не требует перезагрузки ;)

А если серьёзно, то следует попробовать отладить выключение сервисов и узнать, какой сервис вешает систему, а после его подтюнить:
 

Hastra

New member
Сообщения
6
#3
Вы контролируете выключение системы, а после физически отключаете электропитание?
Нет. Физически ничего не отключаю. Выключение и перезагрузка происходят, но с задержкой DefaultTimeoutStartSec.
А если серьёзно, то следует попробовать отладить выключение сервисов и узнать, какой сервис вешает систему, а после его подтюнить:
Точно можно сказать, что проблема в одном из сервисов, отвечающим за NFS. Если перед отключением компьютера размонтировать сетевой ресурс, отключение происходит нормально.
 

Alex-der

New member
Сообщения
130
#4
Ну, тут всё упирается в таймауты и ретраи, большинство из которых определяется в RFC и основано на транспортном протоколе - udp же... Можете смело вручную покрутить sysctl-и на предмет значительного уменьшения, т.к. по умолчанию заданы усреднённые значения для "медленных" сетей передачи данных.
Точно можно сказать, что проблема в одном из сервисов, отвечающим за NFS. Если перед отключением компьютера размонтировать сетевой ресурс, отключение происходит нормально.
Это, помнится, даже было описано в "Руководстве системного администратора *nix" от BHV во 2-м или 3-м издании. Ну и решения два - либо ставить мониторинг живости сервера и отмонтировать в фоне после принятия решения о его смерти, либо уменьшать ретраи и таймауты NFS.

PS: Или вставить проверку и принудительный отстрел процессов nfsd перед завершением работы (что их там-то? штуки 4-5 всего, как я помню?).
 

Hastra

New member
Сообщения
6
#8
может опция lazy при отмонтировании поможет ?
Ручное отмонтирование работает. Даже без опций. Причём всегда. Но если сервер отключается, то происходит зависание на нём (на команде umount) с любыми опциями. Хотя размонтирование происходит даже в этом случае, и при повторном вызове этой же команды зависания не происходит. По-видимому, нечто подобное происходит и при выключении. Но мне нужно, чтобы компьютер нормально выключался и без предварительного ручного размонтирования. Я пробовал использовать свою службу (.service), в которой запускается скрипт с командой размонтирования. Но запустить её не получается: Job for test.service failed because the control process exited with error code. Дело в скрипте, где одна единственная рабочая команда sudo umount 192.168.0.2:/server /client
 

Hastra

New member
Сообщения
6
#10
1. уменьшить таймаут https://unix.stackexchange.com/questions/328317/reducing-shutdown-timeout-for-a-stop-job-is-running
2. почитать про похожую проблему https://github.com/systemd/systemd/issues/12262
3. включить больше лога и думать над ним "Diagnosing Shutdown Problems" https://www.freedesktop.org/wiki/Software/systemd/Debugging/
1. С этого начинал. Если поставить малый таймаут, то вообще не перезагрузится/не выключится. Кроме того, это по сути костыль.
2. Все интернеты уже перечитал и перепробовал множество решений. Да, проблема чаще всего фигурирует у Arch Linux.
3. Почитаем.
Спасибо
 

Hastra

New member
Сообщения
6
#11
РЕШЕНИЕ
Задача, с которой был связан данный вопрос, заключалась в использовании network file system (NFS). При этом, чтобы монтирование сетевого ресурса происходило автоматически, без участия пользователя. Связь должна самостоятельно восстанавливаться после переподключения сервера.
Проблема возникает при потери связи с сервером (например, при обрыве ethernet) после того как было сетевой ресурс был смонтирован. Она заключается в длительном выключении, перезагрузке, иногда с выводом сообщения failed to unmount... . Также возникает зависание менеджера файлов. Если размонтировать ресурс, проблема исчезает.
Решение следующее:
- fstab не используется вообще; всевозможные таймауты, в частности DefaultTimeoutStartSec в /etc/systemd/system.conf не трогаются.
- создаётся скрипт mounter.sh такого плана:
Код:
#!/bin/bash
sleep 4
if ping -c1 -W1 192.168.0.2
then
sudo timeout 1s mount 192.168.0.2:/server /home/user/client
else
sudo timeout 1s umount -f 192.168.0.2:/server /home/user/client
fi
- пишется и активируется служба:
Код:
[Unit]
Description=User service: network file system special mounter
After=network.target

[Service]
Type=simple
ExecStart=/etc/systemd/system/mounter.sh
Restart=always

[Install]
WantedBy=multi-user.target
Эта служба постоянно перезапускается. Возможно, было бы лучше, чтобы она однократно запустила нескончаемый скрипт, не знаю.
Тут, конечно, не совсем верно, что не проверяется состояние - смонтировано или нет, а тупо перемонтируется/передемонтируется время от времени.
Также следует отметить, что после команды sudo systemctl mask --now rpcbind , которая дана в инструкции для борьбы с зависанием графических приложений, отваливаются важные nfs службы, из-за чего astra linux вообще не могла запуститься, зависает.
 

oko

New member
Сообщения
1 254
#12
to Hastra
Использование NFS-шары, увы, весьма критично к сетевым задержкам и доступности ресурса. Что, в целом, логично, учитывая год и изначальную идею ее разработки...
Решение как и все костыли красивое, без шуток. Добавил бы от себя:
  • отказаться от systemd-Unit;
  • внутри скрипта использовать /home/$USER/дальнейший-путь;
  • скрипт разместить в месте, доступном для нужных пользователей;
  • дергать скрипт под нужным пользователем через родной cron этого пользователя (/var/spool/cron/crontabs/имя_юзера) каждые 5-10 минут;
  • ограничить sudo-права для таких юзеров только на mount;
  • проверять наличие уже смонтированного ресурса через if [ $(df -h | grep '/полный-путь-к-точке-монтирования' | wc -l) == '0' ]; then (для случая отсутствия смонтированного ресурса) и не монтировать его повторно;
  • проверять ошибку монтирования ресурса - после sudo mount... писать if [ $? -ne 0 ]; then (для случая ошибки монтирования);
  • логировать все сообщения через echo "уникальная-метка сообщение" | logger.