# NVML Unknown Error после daemon-reload: когда контейнер теряет GPU

Диагностика: NVML Unknown Error после daemon-reload: когда контейнер теряет GPU. Признаки, последовательность проверки, рабочий пример и критерии восстановления.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/nvidia-container-nvml-systemd-reload/
Language: ru

Failed to initialize NVML: Unknown Error после systemctl daemon-reload может соответствовать документированной проблеме legacy NVIDIA runtime hook и обновления cgroup. Проверяйте режим и версии: тот же текст ошибки имеет и другие причины, поэтому совпадение сообщения недостаточно для диагноза.

## Зафиксируйте порядок событий

Сохраните время последнего успешного доступа, daemon-reload или изменения ресурсов контейнера и первого отказа. Проверьте host nvidia-smi и сравните с доступом внутри того же контейнера. Если устройство недоступно и на хосте, область расследования шире runtime injection. Не вызывайте daemon-reload в рабочей среде только для подтверждения догадки. Сначала соберите уже существующие события обслуживания и запланируйте отдельное воспроизведение с допустимым влиянием на тестовый узел.


[Официальный источник 1](https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/troubleshooting.html).

## Определите механизм инъекции

NVIDIA описывает ситуацию, когда legacy hook меняет device/cgroup access вне полного знания low-level runtime. Последующее обновление контейнера может лишить его доступа к GPU. На некоторых systemd cgroup configurations daemon-reload достаточно для такого обновления. Версии runc и драйвера также влияют на отдельные варианты проблемы. Сохраните runtime mode, cgroup driver, versions и способ передачи устройства. CDI имеет другую модель инъекции, поэтому выводы о legacy режиме нельзя автоматически переносить на него.


[Официальный источник 2](https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/cdi-support.html).

## Разделите два уровня доступности

В учебном случае host enumeration остаётся нормальной, а давно запущенный контейнер после события обслуживания теряет NVML access. Новый тестовый контейнер с тем же назначением снова видит GPU. Это поддерживает гипотезу нарушенного контейнерного доступа, но требует сопоставления режима и событий. Перезапуск приложения внутри того же повреждённого контейнера может не восстановить runtime configuration. Документация описывает пересоздание контейнера как восстановительное действие для рассматриваемого случая.

| Наблюдение | Значение для гипотезы |
| --- | --- |
| Хост видит устройство | Отказ локализуется дальше хоста |
| Старый контейнер не видит | Проверять runtime access |
| Новый видит | Сравнить созданную конфигурацию |
| Есть cgroup update | Проверить описанный механизм |

## Подберите совместимое исправление

Документация перечисляет варианты mitigations, включая CDI и особенности запроса device nodes. Не меняйте cgroup driver всего кластера по одной статье: настройка связана с kubelet, runtime и политикой управления узлом. Выберите поддерживаемый способ для конкретной среды, сохраните конфигурацию и оцените соседние workload. Переход на CDI требует проверки discovery и device definitions, а не только замены одного флага в команде запуска.

## Проверьте обслуживание повторно

На тестовом узле повторите предусмотренное изменение и подтвердите доступ до и после него. Сохраните версии, режим инъекции, UUID и результат небольшой вычислительной проверки отдельно от nvidia-smi. Артефакт должен явно указывать, какой сценарий воспроизведён и какой mitigation применён. Если ошибка появляется без cgroup update или только у одного приложения, продолжайте расследование библиотек, прав и других причин. Узкий документированный случай не следует превращать в универсальное объяснение любого сообщения NVML.

Связанные разборы: [gpu maintenance change register](/ru/journal/gpu-maintenance-change-register/); [vllm install compatibility](/ru/journal/vllm-install-compatibility/).