В моем конкретном случае я хочу начать remote-fs единица в конце концов glusterfs полностью запускается.
Мои файлы systemd:
glusterfs цель:
node04:/usr/lib/systemd/system # cat glusterfsd.service
[Unit]
Description=GlusterFS brick processes (stopping only)
After=network.target glusterd.service
[Service]
Type=oneshot
ExecStart=/bin/true
RemainAfterExit=yes
ExecStop=/bin/sh -c "/bin/killall --wait glusterfsd || /bin/true"
ExecReload=/bin/sh -c "/bin/killall -HUP glusterfsd || /bin/true"
[Install]
WantedBy=multi-user.target
remote-fs цель:
node04:/usr/lib/systemd/system # cat remote-fs.target
[Unit]
Description=Remote File Systems
Documentation=man:systemd.special(7)
Requires=glusterfsd.service
After=glusterfsd.service remote-fs-pre.target
DefaultDependencies=no
Conflicts=shutdown.target
[Install]
WantedBy=multi-user.target
Хорошо, все демоны Gluster запускаются успешно, и я хочу смонтировать файловую систему Gluster через NFS, но общий ресурс NFS Gluster готов не сразу после glusterfs.service началось, но через несколько секунд, поэтому обычно remote-fs не может установить его даже относительно Requires и After директивы.
Посмотрим журнал:
Apr 14 16:16:22 node04 systemd[1]: Started GlusterFS, a clustered file-system server.
Apr 14 16:16:22 node04 systemd[1]: Starting GlusterFS brick processes (stopping only)...
Apr 14 16:16:22 node04 systemd[1]: Starting Network is Online.
Apr 14 16:16:22 node04 systemd[1]: Reached target Network is Online.
Apr 14 16:16:22 node04 systemd[1]: Mounting /stor...
Здесь все в порядке, удаленная файловая система (/ stor) кажется смонтированной после запуска glusterfs, так как это должно было соответствовать файлам модулей ... Но следующие строки:
//...skipped.....
Apr 14 16:16:22 node04 systemd[1]: Started GlusterFS brick processes (stopping only).
Какой? GlusterFS подготовился только к этому моменту! А потом мы видим:
//...skipped.....
Apr 14 16:16:23 node04 mount[2960]: mount.nfs: mounting node04:/stor failed, reason given by server: No such file or directory
Apr 14 16:16:23 node04 systemd[1]: stor.mount mount process exited, code=exited status=32
Apr 14 16:16:23 node04 systemd[1]: Failed to mount /stor.
Apr 14 16:16:23 node04 systemd[1]: Dependency failed for Remote File Systems.
Apr 14 16:16:23 node04 systemd[1]: Unit stor.mount entered failed state.
Сбой монтирования, поскольку сервер NFS не был готов, когда systemd попытался смонтировать хранилище.
Из-за недетерминированного характера процесса загрузки systemd иногда (примерно 1 из 10 загрузок) монтирование этой файловой системы при загрузке завершается успешно.
Если монтирование при загрузке не удалось, я могу войти на сервер и вручную смонтировать каталог / stor, поэтому служба NFS Gluster, похоже, работает нормально.
Итак, как начать remote-fs после glusterfsd, т.е. после Started GlusterFS brick processes строка появляется в журнале?
remote-fs кажется, это одна из самых последних целей, поэтому я не могу запустить ее после другой цели "обходного пути", которая на самом деле не требуется remote-fs.
Вы можете проанализировать последовательность загрузки systemd, выполнив следующую команду. Просмотрите выходной файл с помощью веб-браузера, поддерживающего SVG.
systemd-analyze plot > test.svg
Этот график предоставит вам статистику времени последней загрузки, которая предоставит вам более ясную точку зрения на проблему.
Я решил проблему с монтированием NFS, добавив mount команды в /etc/rc.local. Однако я не уверен, будет ли он работать с интеграцией glusterd, стоит попробовать для быстрого исправления. Для того, чтобы systemd запустил rc.local, вам необходимо выполнить следующее условие:
# grep Condition /usr/lib/systemd/system/rc-local.service
ConditionFileIsExecutable=/etc/rc.d/rc.local
Как уже было предложено другими; Я не уверен, действительно ли это зависимость от glusterfsd, а не общая задержка чего-то еще, например, DNS-поиска, который должен быть успешным, чтобы он мог разрешить 'node4' и успешно смонтировать общий ресурс NFS.
Мы столкнулись с этой задержкой, потому что в большинстве наших настроек используется локальный проверяющий преобразователь, который должен быть доступен до того, как другие службы, зависящие от DNS, смогут успешно запуститься.
Решением этой проблемы было создание сценария ExecStartPre, который в основном проверяет доступность конкретных зависимостей снова и снова, пока он не завершится успешно (выход 0) или не истечет время попытки (выход 1).
Убедитесь, что вы выполняете настройку вне основного каталога lib systemd, если можете. Изменение файлов пакетов будет означать, что они, вероятно, будут перезаписаны при следующем обновлении.
Может, ты мог бы добавить это к remote-fs цель:
[Unit]
...
ConditionPathExists=/stor
Может быть, какой-нибудь опрос может помочь. Это не зависит от systemd. Например, я использую mysql -e ';' в цикле, прежде чем делать что-нибудь полезное с mysql.