Вопросы Теги

Debian Buster: Как запустить ZFS после open-iscsi в systemd

У меня установлен Debian 10 (Buster), и я добавил ZFS из Backports. У меня есть 4 iSCSI-LUN, которые я использую как диски для ZFS. Каждый LUN имеет отдельный zpool.

Пока что установка ZFS работает. Но система нестабильна после перезагрузки. Иногда после перезагрузки все тома ZFS восстанавливаются и монтируются правильно, иногда - нет. Я думаю, что это происходит, потому что ZFS не ждет завершения iSCSI.

Я пробовал:

/etc/systemd/system/zfs-import-cache.d/after-open-iscsi.conf 

[Unit]
After=open-iscsi.service
BindsTo=open-iscsi.service

systemd-analysis critical-chain zfs-import-cache.service 

The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

zfs-import-cache.service +1.602s
└─open-iscsi.service @2min 1.033s +286ms
  └─iscsid.service @538ms +72ms
    └─network-online.target @536ms
      └─ifup@eth0.service @2min 846ms
        └─apparmor.service @2min 748ms +83ms
          └─local-fs.target @2min 745ms
            └─exports-kanzlei.mount @2min 3.039s
              └─local-fs-pre.target @569ms
                └─keyboard-setup.service @350ms +216ms
                  └─systemd-journald.socket @347ms
                    └─system.slice @297ms
                      └─-.slice @297ms

Это не решает моих проблем. Вероятно, материал iSCSI не готов, но уже активирован системой, поэтому ZFS не находит свои устройства.

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

systemctl start zfs-import-cache.service
systemctl start zfs-mount.service
systemctl start zfs-share.service
systemctl start zfs-zed.service

zfs mount -a

Это работает, но мне нужно чистое решение.

Чего я действительно не понимаю и что сводит меня с ума, так это то, что в Debian действительно существуют /etc/init.d/scriptname, а также файлы модулей systemd. Какой из них используется? sysvinit или systemd? Почему оба предусмотрены? Какие из них лучше?

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

Спасибо за любую помощь; -)

1
задан 22 November 2019 в 15:22
1 ответ

Рекомендуемый способ сделать это, вероятно, использовать правило udev, но я недостаточно хорошо знаю udev. Это мой текущий обходной путь (пожалуйста, скажите мне, как сделать лучше):

  1. Создайте службу для дискового устройства iSCSI, на котором вам нужно ждать (/dev/sdb1, в моем случае):

    $ sudo EDITOR=vim systemctl edit --force --full dev-sdb1.service

  2. В определении сервиса сделайте так, чтобы ZFS зависела от него.

  3. В определении сервиса заставьте его ждать, пока устройство станет доступным.

3 — сложная часть. Вот что у меня есть:

[Unit]
Description="Monitor the existence of /dev/sdb1"
Before=zfs-import-cache.service
# Requires=dev-sdb1.device
# After=dev-sdb1.device
# I thought this would wait for the device to become available.
# It doesn't, and there appears to be no way to actually do so.

[Service]
Type=oneshot
ExecStart=/bin/sh -c 'while [ ! -e /dev/sdb1 ]; do sleep 10; done'
# pathetic

[Install]
WantedBy=multi-user.target
RequiredBy=zfs-import-cache.service

Очевидно, было бы лучше сделать это без сценария оболочки для опроса устройства. Прочитав документацию, касающуюся модулей устройств, и ответы на следующие вопросы Stack Exchange:

и проверили, что dev-sdb1.device существует после загрузки, я ожидал, что просто смогу заставить zfs-import-cache.service ждать /dev/sdb1, добавив правила 

After=dev-sdb1.device
Requires=dev-sdb1.device

к его определению. Это не работает; он скажет, что служба не удалась с результатом «зависимость» , что бы это ни значило. Я предполагаю, что dev-sdb1.device еще не существует, systemd не знает, что оно будет создано в ближайшее время, и я не могу найти директиву, чтобы сказать: «просто подождите ".

Альтернативные подходы:

  1. Используйте единицу пути вместо сценария оболочки для ожидания устройства. Я не пробовал это.
  2. Добавьте правило udev, соответствующее /dev/sdb или /dev/sdb1 (если возможно), чтобы явно сделать его устройство доступным. Я не пробовал это; Я не понимаю, почему это может помочь (блок устройства уже создается), и я не знаю, как выяснить, будет ли это иметь какие-либо другие последствия для инициализации устройства и в результате что-нибудь сломается.
0
ответ дан 11 May 2021 в 13:26

Теги

Похожие вопросы