multipathd захватил том Longhorn: «mount point busy», хотя ничего не смонтировано

В моей домашней лаборатории под SonarQube пять дней висел в Init:0/2, 2413 раз повторяя одно и то же монтирование:

mount: .../globalmount: /dev/longhorn/pvc-... already mounted or mount point busy.

Очевидное прочтение — залипший mount после грязного ребута. Оно было неверным, и доказательство простое: ошибка пережила полный power cycle всех нод, а именно он залипшие монтирования и снимает.

Идти за устройством, а не за сообщением

Сообщение говорит про точку монтирования, поэтому сначала я проверил монтирования:

mount | grep pvc-6e83 || echo "not mounted anywhere"
for f in /proc/[0-9]*/mounts; do grep -q pvc-6e83 "$f" && echo "$f"; done

Пусто, ни в одном mount namespace. Значит, точка монтирования не занята. Вторая половина сообщения — «busy» — про устройство. Поиск закончила одна команда:

lsof /dev/sdb
# multipath 429 root 10r BLK 8,16

Vendor и model блочного устройства — IET / VIRTUAL-DISK, это iSCSI-таргет Longhorn. А multipath -ll показал карту, построенную прямо поверх него.

Корневая причина

Движок Longhorn v1 отдаёт тома по iSCSI как обычные устройства /dev/sdX. multipathd работал на всех четырёх воркерах с пустым blacklist, посчитал том кандидатом в multipath, построил над ним карту и держал устройство открытым. mount(8) сообщает это как «already mounted or mount point busy» и отправляет искать монтирование, которого нет. Это же объясняет устойчивость к ребуту: multipathd стартует рано и при каждой загрузке захватывает устройство заново.

Данные не были под угрозой: e2fsck -n до любых изменений показал чистую файловую систему.

Исправление

Занести устройства Longhorn в blacklist по vendor и product — не через devnode "^sd.*", который выключает multipath для всего, — затем сбросить карту и перезапустить демон:

blacklist {
    device {
        vendor "IET"
        product "VIRTUAL-DISK"
    }
}

дальше multipath -f <map>, systemctl restart multipathd и удаление пода, чтобы он перемонтировал том. Сначала — бэкап multipath.conf, так что откат — это одно копирование и один рестарт.

Главное — сделать это на каждой ноде. Попался один том, но условие было латентным на всех четырёх воркерах: любой том Longhorn мог быть захвачен при следующем рестарте пода. После этого том ушёл в degraded, пока Longhorn пересобирал реплику; это проходит само, правильное действие — дождаться healthy.

Выводы

• «already mounted or mount point busy» при пустом выводе mount значит, что держат устройство. lsof по блочному устройству заканчивает поиск.
• Если ребут не снимает «залипшее» состояние, оно не залипшее — что-то воссоздаёт его при загрузке.
• Любой ноде с Longhorn v1 и установленным multipath-tools нужен blacklist по vendor/product. Добавь его в bootstrap нод и проверяй после каждой пересборки.
• Чини класс, а не экземпляр: проблема, найденная на одной ноде, часто есть на всех.