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

Use /etc/fstab luke! :

server_ip:/usr/local/pub /pub nfs rsize=8192,wsize=8192,timeo=14,intr

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

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

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

v3 не монтируется

хз что там происходит

Мб логи с клиента покажешь? Заодно и сам посмотришь... :)

Что кроме 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.

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

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

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

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

Я тут параллельно искал как подмонтировать самбовскую шару, и наткнулся на другой диалект конфигов, там два файла почему-то надо создавать, вот посмотрите: https://atkdinosaurus.wordpress.com/2015/08/19/how-to-mount-a-cifs-directory-...

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

Там просто СХД и zfs.

Строки оказались из 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 по нему вообще ничего не выдает, пустую строку.

Не помогло.

И не поможет. 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 в дебиане по дефолту выключен.

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

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

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

Не помогло

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

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

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

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

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

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

[Mount]
TimeoutSec=30

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

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

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

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

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

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

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

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

клиент Debian 9.3

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

network.target

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

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

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

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

О. Отлично.

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

код юнита 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

Это просто цирк какой-то! 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

Я тебе говорил.

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

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

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

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

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

Даже если так — тогда ну вот в том и проблема, что в этом вашем дебиане забили большой и толстый на семантику 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.

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

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

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

А если подключиться к серверу из клиента на FreeBSD (TrueOS)? Получится?

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

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

В каком месте? Активация 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.

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

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

Во всех манах по 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.

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

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

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

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

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

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

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