есть скрипт, запускаемый udev, который работает вечно

Файл /proc/drbd был удален в выпусках DRBD 9.x. Вместо этого вы должны использовать drbdadm status, чтобы получить текущее состояние ресурсов DRBD.

Если вы действительно настаиваете на старом выводе /proc/drbd, вы можете найти его сейчас в sysfs. Обратите внимание, что это только для каждого соединения. Он расположен по адресу:

/sys/kernel/debug/drbd/resources/${resource_name}/connections/${hostname}/0/proc_drbd
2
21.08.2020, 02:08
1 ответ

Закончилось тем, что я разобрался с этим без служб systemd.


Вот старый материал, который не мог работать более 59 секунд:

старое правило udev

cat /etc/udev/rules.d/50 -text -log.rules

ACTION=="add", SUBSYSTEM=="tty", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", RUN+="/bin/bash /scripts/start-log"

старый сценарий

/scripts/start -журнал

BASENAME="$(basename $DEVPATH)"
DEVICE="/dev/$BASENAME"
cat "${DEVICE}" >> somefile

В то время как это работает уже 15 минут или около того:

новое правило udev

cat /etc/udev/rules.d/50 -text -log.rules

ACTION=="add", SUBSYSTEM=="tty", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", ENV{SYSTEMD_WANTS}="log@$env{DEVPATH}.service"

$env{DEVPATH} будет передан службе как обычный аргумент командной строки в переменной bash $1

новая услуга

/etc/systemd/system/log@.service

[Service]
Type=simple
TimeoutSec=0
GuessMainPID=false
ExecStart=/bin/bash -c "/scripts/start-log %I"

или, может быть, используйте TimeoutSec=infinity, похоже, это новый вариант настройки, который работает вечно. Но поскольку =0у меня работает, я не пробовал. (см. man systemd.serviceи перейдите к TimeoutStopSec=, который настроен по сокращениюTimeoutSec=). И я думаю, что мне также нужно было перезагрузиться.

новый скрипт

DEVPATH=$1
BASENAME="$(basename $DEVPATH)"
DEVICE="/dev/$BASENAME"
cat "${DEVICE}" >> somefile

Старая переменная окружения больше недоступна, нужно получить ее через аргументы

1
19.03.2021, 02:27

Теги

Похожие вопросы