LINUX.ORG.RU

Не монтируется nfs на загрузке

 , ,


1

1

Дано: клиент Debian 9.3, NFS сервер FreeBSD 11, хочу монтировать шару NFSv3 на загрузке, вручную все работает, автоматом не хочет.

Делаю как диды завещали через fstab, хз что там происходит, но v3 не монтируется, только v4 (а он подлец биндится не в тот uid, поэтому с такими закидонами и не нужен в данном конкретном случае)

Ну ок, решил на модном systemd написать юнит, например

[Unit]
Description=Cloud NFS share
After=network.target nfs-common.service

[Mount]
What=[адрес сервера]
Where=/mnt/cloud
Type=nfs
Options=_netdev,auto,rw,async,vers=3,hard,intr,rsize=8192,wsize=8192

[Install]
WantedBy=multi-user.target

Включаю, проверяю, опять вручную все работает, но после ребута нет шары. Я же ему все предусловия написал, смотрю в логи...

Jan 23 00:03:02 debian systemd[1]: mnt-cloud.mount: Mount process exited, code=exited status=32
Jan 23 00:03:02 debian systemd[1]: mnt-cloud.mount: Unit entered failed state.

Jan 23 00:35:48 debian systemd[1]: Starting Preprocess NFS configuration...
Jan 23 00:35:48 debian systemd[1]: Started Preprocess NFS configuration.
Jan 23 00:35:48 debian systemd[1]: Reached target NFS client services.
Jan 23 00:35:48 debian kernel: [    3.805149] RPC: Registered tcp NFSv4.1 backchannel transport module.
Jan 23 00:35:48 debian nfs-common[289]: Starting NFS common utilities: statd idmapd.
Jan 23 00:35:48 debian systemd[1]: Started NFS Common daemons.
Jan 23 00:35:48 debian systemd[1]: Mounting Torrent NFS share...
Jan 23 00:35:48 debian systemd[1]: Mounting Cloud NFS share...
Jan 23 00:35:48 debian systemd[1]: Failed to mount Torrent NFS share.
Jan 23 00:35:48 debian systemd[1]: Failed to mount Cloud NFS share.

Если заменить опцию монтированная на v4, то шара монтируется. Хотя по логу видно, что и v3 и v4 выполняются в правильном порядке. А руками юнит запускается с любой версией и шара монтируется и v3 и v4. Если поребутить систему, разок он все же смонтировал одну шару нормально. Значит есть что-то еще, но я найти не могу.

★★★★★

Ответ на: комментарий от Siado

Ну а для кого я писал, старался...

Делаю как диды завещали через fstab, хз что там происходит, но v3 не монтируется

Lordwind ★★★★★
() автор топика

На nfs-сервере логи посмотреть в момент загрзуки клиента, не?

Deleted
()
Последнее исправление: MyLittleLoli (всего исправлений: 1)
Ответ на: комментарий от intelfx

Что кроме syslog смотреть? Часть из него написал. Еще кстати заметил, что в редких удачных случаях перед исполнением юнита есть строки

Jan 23 00:45:56 debian systemd[1]: Starting Preprocess NFS configuration...
Jan 23 00:45:56 debian systemd[1]: Started Preprocess NFS configuration.
А в неудачных случаях они после монтированная (но не всегда), я не знаю ЧТО за процесс/демон/юнит стоит за этими записями.

Lordwind ★★★★★
() автор топика
Последнее исправление: Lordwind (всего исправлений: 1)
Ответ на: комментарий от Lordwind

я не знаю ЧТО за процесс/демон/юнит стоит за этими записями.

Да, это давно известная неадекватность — названия юнитов не логируются, только описания. Точнее, они сохраняются как доп. поля в journald, но в сислог, очевидно, не уходят.

А вообще всё понятно. Не хватает After-зависимости между mount-юнитами и вот этим, который ты цитируешь. В апстриме они уже очень давно расставляются автоматически через remote-fs-pre.target, а в дебиане, видимо, опять мейнтейнеры облажались.

Погрепай «Preprocess NFS configuration» по /lib/systemd/system.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 2)

Вопрос может немного не по теме, но всё же: чем платформа FreeBSD заслужила доверие как сервер NFS?

Infra_HDC ★★★★★
()
Ответ на: комментарий от intelfx

Строки оказались из nfs-config.service. Юнит mount сделал таким:

After=network.target
Requires=nfs-config.service
Requires=nfs-common.service
After=remote-fs-pre.target
Wants=remote-fs-pre.target
Не помогло.

С логами бардак. Если подсмотреть PID юнита из systemctl status, то journalctl по нему вообще ничего не выдает, пустую строку.

Lordwind ★★★★★
() автор топика
Последнее исправление: Lordwind (всего исправлений: 1)
Ответ на: комментарий от Lordwind

Не помогло.

И не поможет. Requires не подразумевает After. Убери всё про remote-fs-pre.target (раз у тебя в дебиане его не используют) и продублируй первые два Requires= такими же After=.

Или, как вариант, проставь зависимости от remote-fs-pre.target до этих юнитов:

systemctl add-wants remote-fs-pre.target nfs-config.service
systemctl add-wants remote-fs-pre.target nfs-common.service

...и тогда убери явные Requires=, а Wants/After=remote-fs-pre.target оставь (хотя они вообще должны создаваться автоматически).

С логами бардак. Если подсмотреть PID юнита из systemctl status, то journalctl по нему вообще ничего не выдает, пустую строку.

Скорее всего потому что journald в дебиане по дефолту выключен.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

проставь зависимости от remote-fs-pre.target до этих юнитов

Стояли по дефолту

продублируй первые два Requires= такими же After=

Не помогло

Я еще покопался в манах, похоже что все условия подразумевают параллельное исполнение. То есть mount не ждет завершения зависимых юнитов. Я продолжаю ребутить систему и у меня успешность монтированная на загрузке где-то около 30%.

ЧСХ, с такой же дебильной логикой я столкнулся еще в Windows XP, которая начала инициализировать устройства и запускать службы параллельно, в отличие от последовательной 2000. Это какой-то позор... (ц)

Lordwind ★★★★★
() автор топика
Ответ на: комментарий от Lordwind

Брр, ну что за нафиг. Ты можешь привести все участвующие юниты (в виде вывода systemctl cat) и хоть какой-нибудь лог загрузки?

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

Извиняюсь, но systemd я только начал курить и не во всем шарю. По таким логам я сам ничерта не могу понять.

Однако удивительный эффект дало сочетание

[Unit]
After=nfs-config.service
Requires=nfs-config.service
After=nfs-common.service
Requires=nfs-common.service

[Mount]
TimeoutSec=30
Успешность монтирования достигла 90-100%. Удивительно здесь то, что таймаут сам по себе не гарантирует успеха (при том, что вся загрузка системы длится секунд 10-15). Но и с такими изменениями проскакивают косяки.

Lordwind ★★★★★
() автор топика
Последнее исправление: Lordwind (всего исправлений: 1)
Ответ на: комментарий от Lordwind

По таким логам я сам ничерта не могу понять.

Ну так покажи их.

Однако удивительный эффект дало сочетание

Это должно работать. Если ты говоришь, что всё равно случаются косяки, значит, какие-то гонки остались и мы что-то не учли. Стоп, а TimeoutSec= играет какую-то роль? Без него не работает?

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

daemon.log (очистил и на первой же загрузке словил косяк): https://pastebin.com/e0ahFyHn

Странно что DHCP получает адрес (хотя аренда не просрочена) через 3 сек и намного позже монтирования и других юнитов.

Стоп, а TimeoutSec= играет какую-то роль? Без него не работает?

По идее дает задержку для завершения монтирования. Без него работает, но успешность около 30% на загрузке.

Lordwind ★★★★★
() автор топика
Последнее исправление: Lordwind (всего исправлений: 1)

клиент Debian 9.3

Я там сеть под systemd-networkd переделывал, когда ловил косяки с юнитами для прог, которые в сеть хотят.

network.target

Там еще есть network-online.target.

Radjah ★★★★★
()
Ответ на: комментарий от Lordwind

По идее дает задержку для завершения монтирования. Без него работает, но успешность около 30% на загрузке.

Просто эта задержка по умолчанию 90 секунд. Я не знаю, чего можно добиться этим таймаутом...

daemon.log (очистил и на первой же загрузке словил косяк): https://pastebin.com/e0ahFyHn

О. Отлично.

Ты можешь показать код юнита nfs-common.service и код скрипта, который этим юнитом запускается?

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

код юнита nfs-common.service и код скрипта, который этим юнитом запускается

[Unit]
Description=NFS Common daemons
Wants=remote-fs-pre.target
DefaultDependencies=no

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/etc/init.d/nfs-common start
ExecStop=/etc/init.d/nfs-common stop

[Install]
WantedBy=sysinit.target

https://pastebin.com/nBHBBjQ1

Lordwind ★★★★★
() автор топика

Это просто цирк какой-то! intelfx, Radjah, Debian у меня свежий, барахлом не оброс, решил Centos поставить рядом и сделать там те же действия. Так там все заработало искаропки, я тупо написал mount и включил его (10 ребутов подряд без косяков). А фокус в том, что условий я поставил еще меньше:

[Unit]
Description=NFS Cloud share
After=network.target

[Mount]
What=[шара]
Where=/mnt/cloud
Type=nfs
Options=_netdev,async,nfsvers=3

[Install]
WantedBy=multi-user.target
Я давно подозревал, что нынче стабильность дебиана означает только стабильную упоротость ментейнеров. Придется свои старые линуксы без systemd сношать до упора, а потом менять на центось.

Lordwind ★★★★★
() автор топика
Ответ на: комментарий от Lordwind

Я давно подозревал, что нынче стабильность дебиана означает только стабильную упоротость ментейнеров

Дай угадаю: сеть настроена через /etc/network/interfaces, а для сетевого интерфейса указано allow-hotplug enpXsY? Если да, то почитай, чем allow-hotplug отличается от auto, а потом подумай ещё раз, кто тут упоротый.

anonymous
()
Ответ на: комментарий от intelfx

А что, в этом вашем дебиане про network-online.target не знают?

В этом нашем дебиане allow-hotplug означает, внезапно, что этого интерфейса может вообще не быть в системе, и потому его статус вообще никак не влияет на network(-online)?\.target. Т.е. использование allow-hotplug означает «мне по барабану, когда там поднимется этот интерфейс, и существует ли он вообще».

anonymous
()
Ответ на: комментарий от anonymous

Даже если так — тогда ну вот в том и проблема, что в этом вашем дебиане забили большой и толстый на семантику network-online.target. Безотносительно того, какой интерфейс allow-hotplug, а какой нет, в systemd network-online.target принято наделять следующим смыслом: «Usually it indicates a configured, routable IP address of some kind.» (c). В systemd-networkd все интерфейсы по дефолту «hotplug», и ничего, как-то всё работает искаропки.

Но что-то мне подсказывает, что традиционная сетевая конфигурялка дебиана (которая /etc/network/interfaces) вообще никак не интегрируется в network-online.target.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

Но что-то мне подсказывает, что традиционная сетевая конфигурялка дебиана (которая /etc/network/interfaces) вообще никак не интегрируется в network-online.target.

$ ls /etc/systemd/system/network-online.target.wants/
networking.service  NetworkManager-wait-online.service
anonymous
()

А попробуй autofs для этого использовать.

rumgot ★★★★★
()
Последнее исправление: rumgot (всего исправлений: 1)
Ответ на: комментарий от intelfx

Гм. Ну, как я и сказал. Семантика игнорируется напрочь.

В каком месте? Активация network-online.target вызывает активацию сервиса networking.service, который поднимает auto-интерфейсы из /etc/network/interfaces и не завершается, пока они не будут сконфигурированы, т.е., например, не будет установлено Wi-Fi-соединение и не будет получен IP-адрес по DHCP.

network-online.target is a target that actively waits until the nework is «up», where the definition of «up» is defined by the network management software.

anonymous
()
Ответ на: комментарий от iZEN

У меня нет клиентов на фряхе, но пока много клиентов на старых линуксах без systemd, там все работает идеально через fstab. Я просто выяснил, что в debian/ubuntu не умеют готовить systemd, так что в топку такое «дружелюбие».

Lordwind ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Во всех манах по systemd написано, что юниты не ждут окончания запуска своих зависимостей. Если я поставлю зависимость от network-online.target, то mount начнет выполняться именно в момент его старта, а не завершения. Но будет время, я постараюсь проверить этот вариант, уже чисто из-за спортивного интереса.

Lordwind ★★★★★
() автор топика
Ответ на: комментарий от Lordwind

Во всех манах по systemd написано, что юниты не ждут окончания запуска своих зависимостей.

Таково поведение по умолчанию. Однако можно изменить его с помощью директив порядка Before= и After=. Т.е. если сервис требует для своего запуска уже запущенного другого сервиса, в его файле указывается:

[Unit]
Requires=сервис
After=сервис

mount-юниты, относящиеся к удалённым ресурсам, получают нужные зависимости автоматически (man systemd.mount):

Network mount units automatically acquire After= dependencies on remote-fs-pre.target, network.target and network-online.target. Towards the latter a Wants= unit is added as well.

anonymous
()
Ответ на: комментарий от Lordwind

Если я поставлю зависимость от network-online.target, то mount начнет выполняться именно в момент его старта, а не завершения. Но будет время, я постараюсь проверить этот вариант, уже чисто из-за спортивного интереса.

Ваша проблема не из-за зависимостей systemd, а из-за использования allow-hotplug в /etc/network/interfaces. Эта директива отключает ожидание поднятия этого интерфейса при загрузке системы.

anonymous
()
Ответ на: комментарий от anonymous

where the definition of «up» is defined by the network management software.

Да, можно сплясать на ушах и вырезать гланды автогеном через задницу, но это не является ожидаемым поведением от network-online.target. Ожидаемое поведение я процитировал. Что толку от «поднимает auto-интерфейсы», если в результате может оказаться, что ни одного адреса машина так и не получила? Это формально валидное поведение, но глупое.

Впрочем, спорить сейчас бессмысленно, это нужно делать с дебиановскими интеграторами и мейнтейнерами networking.service. Спасибо за вклад в решение — я бы и не подумал, что подлянка может оказаться именно здесь.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от Lordwind

Если я поставлю зависимость от network-online.target, то mount начнет выполняться именно в момент его старта, а не завершения.

Если поставишь After= — то будет именно «в момент завершения». Но эта зависимость там и так есть по умолчанию. Проблема может быть в другом, анонимус прав.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.