<TL; DR>
Я настраиваю файловый сервер только для NFSv4 на основе текущего Debian 10 Buster и ядра ntfsd; systemd v241. В nfs-kernel-server сценарий systemd пакета из дистрибутива кажется мне немного странным. Несколько файлов определения сервисов, включая nfs-server.service сам, приходите с настройкой DefaultDependencies=no, так что устройство не получает автоматически Conflicts=shutdown.target зависимость, согласно systemd.service (5):
[С участием
DefaultDependencies=yes] [s] служебные единицы будут иметь зависимости [...] типаConflicts=иBefore=наshutdown.target. Это гарантирует, что нормальные [...] сервисные блоки полностью завершаются до отключения системы.
Ни то, ни другое не предусмотрено явно, в отличие от того, что я видел в других, собственных пакетах systemd. Команда
systemctl show nfs-server.service | egrep '^(Want|Requ|Bind|Bound|Before|After|Confl)'
подтверждает, что это действительно так: таких зависимостей нет. Руководство продолжается,
Только службы, связанные с ранней загрузкой или поздним завершением работы системы, должны отключать эту опцию.
чем сервер NFS точно не является, так как он не может начать обслуживание, пока сеть не будет полностью загружена, и, вероятно, должен прекратить принимать новые запросы и отказываться от нагрузки, как только начнется завершение работы системы.
Это не единственный сервис в пакете с аналогичной настройкой, но больше всего меня беспокоит этот. Я развертываю одноцелевые виртуальные машины в облачной среде, и на файловом сервере может быть нечестивый объем оперативной памяти (64–128 ГБ), и вся она забита по горло системным кешем, как показывает htop (1). А поскольку это машина для хранения файлов, я не могу подобрать слов, чтобы выразить, насколько я хочу, чтобы сервер, как говорится в руководстве, «полностью завершал работу перед выключением системы», особенно с учетом того, что я жертвую долей надежности на производительность с параметрами монтирования ext4 экспортированной файловой системы data=writeback и nobarrier¹.
</TL; DR>
Так что мой вопрос, сведенный к одному предложению:
Что происходит с сервисом systemd, у которого нет Conflicts= и Before= зависимости от shutdown.target когда система фактически отключается?
¹ Это хорошо продуманный инженерный компромисс, оцениваемый по соглашению об уровне обслуживания поставщика облачных услуг и результатам серии тестов производительности, и он полностью не влияет на суть вопроса.