WCHAN = 0 для спящей задачи?
systemd имеет метод расширения файлов конфигурации, называемый «вставными модулями». Попробуйте создать этот файл:
/etc/systemd/system/networking.service.d
Добавьте в этот файл:
[Service]
ExecStartPost=/sbin/ifconfig -a
Эффект должен заключаться в расширении сетевой службы системы с помощью дополнительной директивы, которая запускается после службы начал.
Подробнее о подключаемых модулях можно прочитать в man systemd.unit . Вы можете найти документацию для ExecStartPost и всех других директив systemd, проверив man systemd.directives .
Кажется, что значение WCHAN вычислено. Из исходников ядраarch/x86/Kconfig:
config SCHED_OMIT_FRAME_POINTER
Single-depth WCHAN output
Calculate simpler /proc/<PID>/wchan values. If this option
is disabled then wchan values will recurse back to the
caller function. This provides more accurate wchan values,
at the expense of slightly more scheduling overhead.
и изDocumentation/filesystem/proc.txt:
wchan Present with CONFIG_KALLSYMS=y: it shows the kernel function
symbol the task is blocked in - or "0" if not blocked.
так что я предполагаю, что иногда имеет место неправильный расчет wchan.
Обратите внимание, что состояние процесса и wchan не возвращаются ядром атомарно.
Это означает, что между доступом к состоянию процесса и получением информации о его канале его состояние вполне может измениться с спящего на работающее.
Таким образом, есть гонка.
Процедура прохода по стеку внутри ядра для получения информации о wchan также весьма забавна и может не охватывать все случаи.
Вы можете перекрестить -проверку сcat /proc/$pid/stack(root -только )или cat /proc/$pid/syscall, чтобы получить дополнительную информацию о том, где процесс застрял в ядре.