Вы хочете лулзов? Их есть у меня.

Но зачем в systemd? Или это зависимость софта? Все равно я верю, что софту свой soft-ctl лучше писать на /bin/sh без башизмов.

Писечка не в этом. На самом деле правила udev кривые — они не могут на несколько строк быть. Лулз в том, как systemd это обрабатывает.

А он реально это обрабатывает и перегружает машину или просто падает и за собой все утягивает?

На самом деле правила udev кривые — они не могут на несколько строк быть.

А так?

SUBSYSTEM=="scsi_generic", ATTRS{type}=="5", ATTRS{model}=="ARCHIVER*", \
  IMPORT{program}="scsi_id --sg-version=3 --export --whitelisted -d $devnode", \
  SYMLINK+="archiver/drive-$env{ID_SCSI_SERIAL}"

Аяхз, в логах бинарная ахинея. В смысле /var/log/daemon.log (куда udev пишет) забит бинарным мусором в конце, а в journalctl вообще ни слова про какие-то проблемы.

Должно, наверное. Сейчас перечитаю мануал.

отличный баг, можно смело репортать!

На другой машине с той же центосью работает (видимо из-за другого набора железа). Чудеса детерминированности.

в логах бинарная ахинея

Мы вас кагбэ предупреждали. Ну теперь жрите г-но. Чорд, мне и самому приходилось ковыряться в 7-й центоси... :(

Мы вас кагбэ предупреждали. Ну теперь жрите г-но. Чорд, мне и самому приходилось ковыряться в 7-й центоси... :(

О чем? Это текстовый лог, я не знаю, откуда там мусор.

Не, в доках написано, что нельзя.

Это текстовый лог, я не знаю, откуда там мусор.

С файловой системой точно всё нормально, RAID не посыпался?
А то симптомы очень похожи.

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

А кто именно в этот лог пишет, проверяли ? SystemD ведь вроде по-умолчанию использует свой journald - и пробрасывает данные в традиционный syslog демон.

А кто именно в этот лог пишет, проверяли ? SystemD ведь вроде по-умолчанию использует свой journald - и пробрасывает данные в традиционный syslog демон.

В этот лог пишет rsyslog.

У вас срабатывает ядерный ватчдог, потому что scsi_id его открывает и не закрывает.

В общем, как всегда — сами виноваты. А ещё ядерщики.

уверены ? процесс journald в системе не запущен ? настройки journald смотрели ?

Но если действительно так, то ХЗ тогда почему ваши логи превращаются в тыкву. Может корень отмонтируется не правильно. Если у вас корень и логи на EXT4 - попробуйте смонтировать корень с опцией data=journal

У вас срабатывает ядерный ватчдог.

Щито?

А ты в логи посмотри, лол. «watchdog0: watchdog did not stop!» перед самым ребутом.

Но если действительно так, то ХЗ тогда почему ваши логи превращаются в тыкву. Может корень отмонтируется не правильно. Если у вас корень и логи на EXT4 - попробуйте смонтировать корень с опцией data=journal

Чувак, я вообще не уверен, что там что-то отмонтируется. Просто консоль замораживается нахрен и система моментально уходит в ребут.

А ты в логи посмотри, лол.

Я уже выше написал, почему я не могу этого сделать :)

Искренне жаль. Запустись в rescue и вбей dmesg -w.

Искренне жаль. Запустись в rescue и вбей dmesg -w.

Ты мне лучше скажи, на что он срабатывает.

P.S. Я уже не говорю о том, что делать dmesg после перезагрузки довольно бессмысленно.

P.S. Я уже не говорю о том, что делать dmesg после перезагрузки довольно бессмысленно.

Ты серьёзно или прикидываешься? Вбей dmesg -w и посмотри, как у тебя сначала появится сообщение ватчдога, а потом через несколько секунд после него система уйдёт в ребут.

Ты мне лучше скажи, на что он срабатывает.

Я уже сказал: scsi_id, который у вас из-за ошибке в правиле запускается для всех устройств, открывает chardev ватчдога и не останавливает его впоследствии. Дальше продолжать?

# /lib/udev/scsi_id --sg-version=3 --export --whitelisted -d /dev/watchdog0
# /lib/udev/scsi_id --sg-version=3 --export --whitelisted -d /dev/watchdog0

Пока все ок.

Просто ради интереса, попробуй такое правило:

# Magazine loader
SUBSYSTEM=="scsi_generic", ATTRS{type}=="8", ATTRS{model}=="ARCHIVER*",
  KERNEL!="watchdog*", IMPORT{program}="scsi_id --sg-version=3 --export --whitelisted -d $devnode",
  SYMLINK+="archiver/loader-$env{ID_SCSI_SERIAL}"

# Writer unit
SUBSYSTEM=="scsi_generic", ATTRS{type}=="5", ATTRS{model}=="ARCHIVER*",
  KERNEL!="watchdog*", {program}="scsi_id --sg-version=3 --export --whitelisted -d $devnode",
  SYMLINK+="archiver/drive-$env{ID_SCSI_SERIAL}"

Ну вообще да, свалился. Теперь остается понять, почему на другой системе с таким же watchdog'ом все ок.

Ну вообще да, свалился.

ЧТД.

Теперь остается понять, почему на другой системе с таким же watchdog'ом все ок.

Потому что на сабжевой CONFIG_WATCHDOG_NOWAYOUT или nowayout в параметрах модуля ватчдога?

Потому что на сабжевой CONFIG_WATCHDOG_NOWAYOUT или nowayout в параметрах ядра?

Если руками дергать — падает.

Руками падает на обоих, а через правило — только на одной? Хз, перепроверь.

Руками падает на обоих, а через правило — только на одной? Хз, перепроверь.

Два раза уже. Похоже, что на второй машине почему-то правило не срабатывает для watchdog'а.

Хз. У вас только одно устройство ватчдога? Попробуй watchdog1. У меня на десктопе тоже watchdog0 нормально закрывается, а watchdog1 — нет. Один от iTCO, другой от MEI (или наоборот).

Хз. У вас только одно устройство ватчдога? Попробуй watchdog1. У меня на десктопе тоже watchdog0 нормально закрывается, а watchdog1 — нет. Один от iTCO, другой от MEI (или наоборот).

На обеих машинах только один. Но вообще, сообщение должно быть вида

FUCK FUCK FUCK WATCHDOG WAS NOT CLOSED PANIC TRIGGERED IN 10 FUCKING SECONDS

потому что, если честно, я про watchdog забыл напрочь.

watchdog1: watchdog did not stop!

У этого сообщения priority «error». Недостаточно?

По сабжу — хз, почему на второй машине всё ок.

Тут есть хоть слово о том, что через десять секунд мы все умрем?

Предлагаю написать в спортлото вот сюда:

$ git --no-pager grep 'did not stop!' drivers/watchdog
drivers/watchdog/watchdog_dev.c:                pr_crit("watchdog%d: watchdog did not stop!\n", wdd->id);

$ scripts/get_maintainer.pl drivers/watchdog/watchdog_dev.c
Wim Van Sebroeck <wim@iguana.be> (maintainer:WATCHDOG DEVICE DRIVERS)
Guenter Roeck <linux@roeck-us.net> (reviewer:WATCHDOG DEVICE DRIVERS)
linux-watchdog@vger.kernel.org (open list:WATCHDOG DEVICE DRIVERS)
linux-kernel@vger.kernel.org (open list)

P. S.: О, даже не err, а crit.

Да, я думаю, что стоит добавить проверку на скорое умирание и писать об этом сюда. Зашлю в LKML.

crit мало о чем говорит. У меня термальные датчики на ляптопе постоянно туда орут.

Не, в доках написано, что нельзя.

А по факту есть. Или что-то тут не так. Вот, например, из /lib/udev/rules.d/60-persistent-input.rules:

# allow empty class for USB devices, by appending the interface number
SUBSYSTEMS=="usb", ENV{ID_BUS}=="?*", KERNEL=="event*", ENV{.INPUT_CLASS}=="", ATTRS{bInterfaceNumber}=="?*", \
  SYMLINK+="input/by-id/$env{ID_BUS}-$env{ID_SERIAL}-event-if$attr{bInterfaceNumber}"

Ну вот все, что есть в мане по этому поводу:

$ man udev | grep -E '(\\|slash)'
           and \x00 hex encoding. All other characters are replaced by a