Debian/Ubuntu: как диагностировать systemd-udevd seq timeout и зависания udev

Если в журнале Debian или Ubuntu появляются строки вида systemd-udevd seq timeout, это почти всегда симптом, а не корневая причина. Сам systemd-udevd обычно лишь обрабатывает события устройств, которые приходят из ядра: подключение диска, появление сетевого интерфейса, изменение атрибутов блочного устройства, загрузка модуля, реакция на правила в /usr/lib/udev/rules.d и /etc/udev/rules.d. Когда какое-то событие обрабатывается слишком долго, очередь начинает тормозить, а затем в логах всплывает timeout.

На практике администратор чаще всего видит одну из трёх картин: сервер медленно грузится, периодически подвисает инициализация устройств после обновления ядра или системы, либо проблема проявляется точечно — например, при подключении USB, виртуального диска, loop-устройства, LVM-тома, NVMe или сетевого адаптера в виртуальной машине. Встречается и сценарий, когда всё начинается после неудачного кастомного правила udev, запускающего слишком тяжёлый скрипт.

Ключевая мысль простая: искать надо не способ «перезапустить udev и забыть», а конкретный event, конкретное устройство, правило или драйвер, из-за которого очередь перестала нормально обрабатываться. Иначе можно лишь приглушить симптом, но оставить причину, которая позже проявится как потеря устройства, ошибка монтирования, таймаут при загрузке или заметная деградация производительности.

Ещё один важный момент: не всякий udev timeout одинаково опасен. Если это редкий таймаут на тестовом USB-адаптере — одна история. Если же после него не поднимается корневой диск, зависает LUKS, mdadm, multipath или сетевой интерфейс на проде — действовать надо быстро, но аккуратно.

Ниже разберём рабочую схему диагностики: как собрать признаки, как использовать udevadm monitor, когда запускать udevadm trigger, что проверять в dmesg, как временно изолировать проблемное правило и как понять, виновато ли пользовательское пространство, systemd, драйвер или само устройство.

Что означает systemd-udevd seq timeout

Сообщение с seq timeout связано с последовательным номером события udev. Каждое событие от ядра получает свой номер и проходит обработку через цепочку правил. Если обработка затягивается дольше допустимого времени, демон пишет предупреждение о таймауте конкретной последовательности. Это не обязательно означает, что демон завис целиком, но почти всегда говорит о том, что одно из событий не завершилось вовремя.

Причины обычно лежат в одной из следующих зон:

• медленный или неисправный драйвер устройства;
• аппаратная проблема диска, USB, контроллера, PCIe или виртуального устройства;
• правило udev, запускающее внешний скрипт или утилиту, которая подвисает;
• ожидание ответа от подсистем хранения, LVM, mdadm, multipath, cryptsetup;
• задержки после обновления ядра, initramfs или пакетов с правилами udev;
• особенности виртуальной среды: hotplug, нестабильный virtio, passthrough-устройства.

Если в логах есть только строка про systemd-udevd seq timeout, этого недостаточно для вывода. Всегда сопоставляйте её по времени с сообщениями ядра, событиями устройств и последними изменениями в системе.

С чего начать диагностику

Первый шаг — зафиксировать контекст. Когда именно возникает ошибка: при загрузке, после обновления, при подключении устройства, при старте контейнеров, после восстановления снапшота, во время рескана шин или при создании loop- и LVM-устройств? Это сразу сужает круг поиска.

Дальше полезно собрать минимальный набор данных: журнал текущей загрузки, сообщения ядра, сведения о версиях systemd и ядра, а также список недавно изменённых правил udev. На сервере удобнее работать в отдельной сессии, чтобы не потерять контекст и быстро сравнивать вывод нескольких команд.

uname -a
systemctl --version
journalctl -b -u systemd-udevd
journalctl -b -k
journalctl -b | grep -Ei 'udev|systemd-udevd|timeout|seq'
dmesg -T | grep -Ei 'udev|timeout|blk|sd[a-z]|nvme|usb|scsi|virtio|firmware|failed|error'

Если проблема появилась после апдейта, сразу проверяйте историю пакетов и версий ядра:

grep -Ei 'upgrade|install|systemd|udev|linux-image|initramfs' /var/log/dpkg.log
ls -1 /boot
apt list --installed 2>/dev/null | grep -Ei 'systemd|udev|linux-image|initramfs-tools'

Уже на этом этапе часто видно, что timeout совпал, например, с I/O error, reset устройства, повторными попытками инициализации USB-контроллера, зависанием nvme, жалобами virtio или сообщениями о том, что пользовательский helper не завершился вовремя.

Как посмотреть живые события через udevadm monitor

Когда проблема воспроизводится по требованию, лучший инструмент — udevadm monitor. Он показывает события ядра и события, которые уже видит udev. Это позволяет понять, где именно поток ломается: событие не приходит вовсе, приходит только от ядра, но не доходит до правила, либо доходит и дальше всё зависает.

udevadm monitor --kernel --udev --property

Команду лучше запускать заранее, а затем воспроизводить проблему: подключить диск, инициировать hotplug, перезапустить сервис, который создаёт loop-устройства, подключить том, пересканировать SCSI или вызвать триггер для нужной подсистемы. Если после появления события монитор показывает начало обработки, но дальше система молчит, вы уже сузили зону до конкретного устройства или класса устройств.

Полезный приём — открыть рядом ещё одну консоль с ядром:

journalctl -kf

Так вы увидите, не сопровождается ли событие reset-ами контроллера, таймаутами шины, сообщениями ACPI, ошибками firmware или повторными попытками чтения атрибутов устройства.

Если проблема плавающая и возникает только на виртуальной машине под нагрузкой, заранее подумайте о среде, где удобнее воспроизводить такие сценарии. Для подобных разборов обычно практичнее использовать отдельный VDS, где можно безопасно перезапускать сервисы, тестировать hotplug и проверять поведение после обновлений без риска для основной инфраструктуры.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Как безопасно использовать udevadm trigger

udevadm trigger заново генерирует события для уже известных устройств. Это удобно, когда нужно перепроверить воспроизводимость без физического переподключения железа. Но на прод-сервере запускать триггер бездумно на все подсистемы не стоит: можно спровоцировать шквал событий и усложнить картину.

Безопаснее начинать с конкретного класса устройств или конкретного пути. Например, только для блочных устройств:

udevadm trigger --subsystem-match=block
udevadm settle --timeout=30

Или сначала получить путь проблемного устройства:

udevadm info --query=path --name=/dev/sda
udevadm trigger --path=/devices/pci0000:00/0000:00:05.0/virtio2/block/vda
udevadm settle --timeout=30

Если после udevadm trigger снова появляется timeout, а в параллельном мониторинге видно конкретное устройство, это уже почти готовая зацепка. Дальше можно исследовать атрибуты и применяемые правила.

Как понять, какое правило udev срабатывает

Одна из самых частых причин — неудачное пользовательское правило. Обычно это правило с RUN+=, реже с импортом внешней информации, вызовом helper-утилиты или попыткой сделать через udev то, что правильнее вынести в отдельный сервис systemd.

Сначала смотрим атрибуты устройства:

udevadm info --attribute-walk --name=/dev/sda
udevadm info --query=all --name=/dev/sda

Потом проверяем тестовую обработку, не дожидаясь реального hotplug:

udevadm test /sys/class/block/sda

Вывод udevadm test обычно показывает, какие файлы правил читались и какие строки сработали. Если вы видите кастомное правило из /etc/udev/rules.d, которое запускает скрипт, проверьте этот скрипт отдельно. Очень часто он зависает из-за обращения к сети, ожидания DNS, доступа к недоступному диску, блокировки файла или запуска команды, не рассчитанной на среду udev.

Отдельно полезно просмотреть пользовательские правила:

find /etc/udev/rules.d -maxdepth 1 -type f -print
sed -n '1,200p' /etc/udev/rules.d/*.rules

Если в правилах есть тяжёлые действия, хорошая практика — временно отключить подозрительное правило, перечитать конфигурацию и повторить тест. На удалённом сервере делайте это особенно осторожно, если правило связано с сетью, дисками или правами устройств.

Во многих случаях вместо длинного shell-скрипта в RUN+= лучше запускать отдельный systemd-сервис. Если вы как раз выносите тяжёлую обработку из udev в фоновые сервисы, полезно посмотреть и схожий сценарий с очередями и воркерами: как организовать фоновые workers через systemd.

Что искать в dmesg и journalctl

Команда dmesg почти всегда даёт больше пользы, чем повторное чтение одной строки про timeout. Ищите всё, что совпадает по времени с проблемой:

• ошибки чтения и записи, reset устройств, таймауты SCSI и NVMe;
• повторную инициализацию USB, PCIe AER, ACPI и firmware warnings;
• зависшие helper-процессы или жалобы на firmware loading;
• проблемы с loop, dm, device-mapper, mdadm, cryptsetup;
• ошибки виртуальных драйверов virtio, xen, hv_*.

dmesg -T | tail -n 200
journalctl -b -k -g timeout
journalctl -b -g 'seq timeout'
journalctl -b -g 'worker'
journalctl -b -g '/dev/'

Если видно, что timeout идёт вместе с I/O-ошибками, проблема, скорее всего, ниже уровня udev. Если же ядро чистое, а в логе фигурирует конкретное правило или helper, причина чаще находится в пользовательской логике.

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

Типовые сценарии проблем

Подвисает правило с RUN+=

Это классика. В udev не стоит помещать тяжёлые, долгие и особенно сетевые операции. Скрипт, который делает DNS-запрос, ждёт монтирование, пишет в медленный каталог, вызывает Python с множеством импортов или запускает другую долгую команду, быстро приводит к накоплению очереди. Если логика действительно нужна, лучше из правила инициировать отдельный сервис systemd, а не выполнять всё внутри обработки события.

Проблемный диск или виртуальное блочное устройство

Если в dmesg рядом идут I/O error, reset, retry или сообщения от sd, scsi, nvme, dm-*, смотрите сначала на уровень хранения. Udev здесь всего лишь ждёт, пока ядро и драйвер закончат работу. В виртуальной машине не исключайте и проблемы на стороне гипервизора: нестабильный hotplug, временно недоступный том, сбойный virtio-диск.

После обновления изменилась логика правил

Иногда после обновления systemd, initramfs или пакета драйверов старые локальные правила начинают конфликтовать с новыми системными. Особенно если правило писалось давно и опиралось на имена устройств, которые теперь формируются иначе, или на атрибуты, которые больше не доступны в ожидаемом порядке.

Сервер тормозит на загрузке

Если timeout виден именно при boot, стоит проверить не только журнал systemd-udevd, но и критическую цепочку загрузки. Иногда проблема выглядит как udev, а на деле это ожидание device unit, сетевого тома, cryptsetup или device-mapper.

systemd-analyze blame
systemd-analyze critical-chain

Пошаговый план локализации

1. Зафиксируйте время и контекст появления timeout.
2. Соберите journalctl -b и dmesg -T вокруг этого времени.
3. Определите подсистему: block, net, usb, pci, input, tty, drm и так далее.
4. Запустите udevadm monitor --kernel --udev --property и воспроизведите проблему.
5. Если известно устройство, проверьте его через udevadm info и udevadm test.
6. Просмотрите кастомные правила в /etc/udev/rules.d.
7. Временно исключите подозрительные правила или helper-скрипты.
8. Если в ядре есть аппаратные ошибки, переключайтесь на диагностику диска, контроллера, шины или виртуального устройства.
9. Если проблема возникла после обновления, сравните версии ядра и systemd, проверьте загрузку с предыдущим ядром.

Что не стоит делать

Есть несколько типичных ошибок, которые мешают расследованию:

• бездумно запускать udevadm trigger на всё дерево устройств в рабочее время;
• массово удалять системные правила без резервной копии;
• лечить проблему только перезапуском systemd-udevd без анализа логов;
• оставлять долгие shell-скрипты внутри правил udev;
• игнорировать сообщения ядра, если кажется, что виноват именно udev.

Если сервер удалённый и проблема затрагивает диск или сеть, сначала обеспечьте аварийный доступ: дополнительную SSH-сессию, консоль провайдера, rescue-режим или снимок состояния. Диагностика udev на боевой машине требует осторожности.

Когда проблема в systemd-udevd, а когда нет

Реальные баги в самом systemd-udevd бывают, но заметно реже, чем проблемы вокруг него. Если timeout начал появляться сразу после обновления systemd и воспроизводится на нескольких однотипных машинах без аппаратных ошибок и без локальных правил, тогда гипотеза о регрессии уже разумна. Но даже в этом случае сначала нужно исключить окружение: кастомные правила, сторонние пакеты драйверов, экзотические устройства и особенности виртуализации.

Хороший признак внешней причины — когда один и тот же timeout сопровождается повторяющимися симптомами на одном и том же устройстве. Например, всегда страдает конкретный NVMe, определённый USB-адаптер или одно локальное правило, работающее только на одном классе томов.

Если вы держите критичные сервисы на собственных серверах, заранее полезно иметь удобную площадку для экспериментов и отладки загрузки. Для таких задач обычно подходит отдельный облачный VDS, где можно безопасно проверить поведение после обновления ядра, systemd и initramfs.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Практический пример короткого расследования

Допустим, после обновления ядра вы видите периодические systemd-udevd seq timeout. В journalctl -b -u systemd-udevd заметно время проблемы, а в dmesg рядом — сообщения о повторном чтении атрибутов dm-0. Через udevadm monitor становится ясно, что зависание происходит на событиях блочных устройств.

Запуск udevadm test для соответствующего sysfs-пути показывает срабатывание локального правила с RUN+=, которое вызывает shell-скрипт проверки тома. Сам скрипт ждёт завершения команды, обращающейся к ещё не готовому mapper-устройству. В итоге очередь udev подвисает, а в журнале появляется timeout.

Решение в таком случае — не увеличивать вслепую таймаут, а убрать тяжёлую логику из правила и перевести её в отдельный сервис, который запускается после появления устройства и имеет собственные ограничения, логи и механизм рестарта.

Итоги

systemd-udevd seq timeout — это не диагноз, а индикатор зависшего или слишком долгого события. Чтобы исправить проблему в Debian или Ubuntu, полезно мыслить по цепочке: событие ядра, конкретное устройство, конкретное правило, конкретный helper или драйвер. Базовый набор инструментов здесь простой и надёжный: udevadm monitor, udevadm trigger, udevadm test, dmesg, journalctl.

Если подходить к разбору последовательно, источник обычно находится довольно быстро: либо это аппаратная деградация, либо неудачное правило, либо регресс после обновления, либо особенность виртуального окружения. А попытка лечить только симптом почти всегда заканчивается повторением инцидента.

Для прод-серверов правило простое: минимальная логика в udev, максимум наблюдаемости и аккуратные воспроизводимые тесты. Тогда даже неприятный systemd-udevd hang превращается из загадки в обычную техническую задачу.