Запуск .mount после isc-dhcp-server в systemd в debian 11

Выглядит все как глупость. При чем тут вообще dhcp-сервер?

На сервере поднимается dhcp с помощью isc-dhcp-server.

явно не понимаешь, что пишешь. Какой dhcp и зачем он поднимается?

Вообще говоря, рекомендуется монтировать ФС через fstab, а не создавать юниты напрямую. Там можно написать _netdev в столбце опций и systemd сам всё поймёт.

Но выше правильно написали, что у тебя какая-то каша. Для начала определись, тебе нужен DHCP-сервер или всё-таки DHCP-клиент? И да, всё это можно делать через networkd. Если в твоём дистрибутиве он есть и актуальный — не поленись, перепиши конфиг, будет проще и удобнее.

Я такие файловые системы не монтирую, а добавляю юнит *.automount. Там же заодно можно указать таймаут для автоотмонтирования.

В этом случае они монтируются при обращении к директории, и это по сути самый поздний момент, после всего и только по необходимости.

Извините, долго не отвечал.

Как появилось время ещё посидел покопался.

У меня управляющий узер(сервер о котором я писал) является DHCP-сервером (если я правильно это называю), но к нему также подмонтируются разделы с СДХ. Т.е. не существует отдельного физического сервера задачи которого просто создавать сеть и все. Это осуществляется на управляющем узле о котором я говорю. Так как СДХ перезагружается крайне редко, то описываемая ситуация происходит при перезагрузке управляющего узла и, в идеале, в процессе загрузке системы должна создастся dhcp сеть, СДХ уже будет знать свой ip (так как сервер, только что перезагружен) и нужные папки должны будут подмонтироваться, а затем уже загружаться другие сервисы, такие как например slurm, конфиг которой лежит в общей папке на СДХ. Теперь по поводу того, почему все не работает так, как мне бы хотелось. Насколько я понимаю, по умолчанию модуль .mount грузится до remote-fs.target, при этом согласно конфигу, который сформирован автоматически systemd из init.d/isc-dhcp-server

systemctl cat isc-dhcp-server

[Unit]
Documentation=man:systemd-sysv-generator(8)
SourcePath=/etc/init.d/isc-dhcp-server
Description=LSB: DHCP server
Before=multi-user.target
After=remote-fs.target
After=network-online.target
After=slapd.service
After=nss-lookup.target
Wants=network-online.target

[Service]
Type=forking
Restart=no
TimeoutSec=5min
IgnoreSIGPIPE=no
KillMode=process
GuessMainPID=no
RemainAfterExit=yes
SuccessExitStatus=5 6
ExecStart=/etc/init.d/isc-dhcp-server start
ExecStop=/etc/init.d/isc-dhcp-server stop

Т.е. существует строчка After=remote-fs.target, которая и заставляет dhcp-сервер запускаться позже. Если попытаться, что то изменить, т.е. systemctl edit isc-dhcp-server и добавить

[Unit]
Before=remote-fs.target

то это противоречит основному телу [Unit] и вызывает ошибку при загрузке системы и ‘skipping Remote File System’

Есть ли какой либо более менее простой способ заставить систему грузить сервесы в нужном мне порядке или придется использовать отдельный физический сервер для создания DHCP сети. Ну или есть альтернатива в виде .automount, но скорее всего в этом случае будут те же проблемы при поднятие серверов при загрузке, которые используют конфиги в общих папках.

А меня беспокоит другой вопрос, что такое СДХ ?

Система хранения данных. В данном случае отдельный сервер с дисками.

А зачем вы раз за разом допускаете ошибку при написании аббревиатуры?

должна создастся dhcp сеть

Не знаю, что вы под этим подразумеваете, но после запуска dhcp-сервер просто слушает запросы. Неведомо, когда клиенты захотят отправить запрос, получить ip-адрес, назначить его себе на интерфейс, чтобы стать частью сети.

СДХ уже будет знать свой ip

По идее, при обычной перезагрузке сервера, ваш СДХ/СХД должен помнить ранее выданый ip-адрес. То есть запуск dhcp-сервера не влияет на проблему монтирования. Или dhcp-сервер при завершении работы отзывает выданые ip-адреса?

Мне вобще не понятно, зачем фиксированым устройствам указывают получение адреса по dhcp?, Если СДХ/СХД будет заменён, всё одно переписывать конфиг dhcp, так как будет другой mac-адрес.

Чем не устраивает automount? А так, вам нужно чтобы юнит монтирования запускался после получения ip-адресах СХД.

Я такие файловые системы не монтирую, а добавляю юнит *.automount. Там же заодно можно указать таймаут для автоотмонтирования.

И это тоже рекомендуют делать опцией x-systemd.automount в fstab.

Т.е. существует строчка After=remote-fs.target, которая и заставляет dhcp-сервер запускаться позже. Если попытаться, что то изменить, т.е. systemctl edit isc-dhcp-server и добавить

Предлагаю сменить дистрибутив на вменяемый, т. е. на такой, в котором юнит для isc-dhcp-server написан вручную, а не сгенерирован из (криво написанного) SysV-скрипта. Потому что никакого After=remote-fs.target в этом юните по смыслу быть не должно.

А если серьёзнее, то в вашем локальном патче (который вы редактируете командой systemctl edit) нужно сделать так:

[Unit]
After=
After=network-online.target slapd.service nss-lookup.target
Before=remote-fs-pre.target

И да, вам нужно не Before=remote-fs.target, а Before=remote-fs-pre.target.

Хотя на самом деле это всё бесполезно. Между запуском DHCP-сервера и попыткой примонтировать ФС пройдёт очень мало времени, считанные миллисекунды. Вы точно уверены, что за это время СХД успеет обновить аренду и стать доступной по нужному адресу? Иначе достучаться до СХД всё равно не удастся.

И в любом случае не понятно, почему перезагрузка «управляющего сервера» должна заставить СХД потерять аренду. Если он правда её теряет, то мне кажется, что сеть попросту абсолютно неправильно спроектирована.

Согласен, исправлюсь.

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