Нахрена

Затем, что udev синхронен и запрещает долгоживущие воркеры (он их убивает через некоторое непродолжительное время). И, имхо, запускать через systemd удобнее — можно отследить, сфейлился бэкап, или не сфейлился, что написал в лог, или там что-то запустить по окончании бэкапа...

/lib/udev/rules.d/*.rules

/etc/udev никуда не делся.

У меня есть велосипед для бэкапа bup-ом при загрузке системы (когда корень всё ещё подмонтирован в RO). Нужно?

/etc/udev никуда не делся.

Умолчательное место для установки в gentoo стало /lib/udev/rules.d/*.rules а не /etc/…

У меня есть велосипед для бэкапа bup-ом при загрузке системы (когда корень всё ещё подмонтирован в RO). Нужно?

Мне нужно любое работающее решение для разбора. Потому что я знаю как было но вот к примеру это

Затем, что udev синхронен и запрещает долгоживущие воркеры (он их убивает через некоторое непродолжительное время).

Для меня новость. Потому что до systemd в качестве запускателя программ при появлении устройств выступал именно udev. Сейчас велосипедят конструкцию {появился девайсик} -> udev -> systemd -> свой велосипед

Умолчательное место для установки в gentoo стало /lib/udev/rules.d/*.rules а не /etc/…

Что понимать под умолчательным? system-wide ставятся в /lib, пользовательские в /etc. Вроде всегда так было.

в качестве запускателя программ при появлении устройств выступал именно udev.

Если форкаться и становиться демоном, то можно и так. Собственно, кто запрещает? =)

Мне нужно любое работающее решение для разбора.

Тогда, видимо, моё не подойдёт, т. к. я там использую только systemd: требую (Requires=) монтирования целевой ФС, потом требую монтирования устройств из целевого списка и по мере появления их бэкаплю.

Впрочем, если всё же подойдёт, то ftp://intelfx.homenet.org/bup-scripts.tar

Что понимать под умолчательным?

systemd_dounit из systemd.eclass

Если форкаться и становиться демоном, то можно и так. Собственно, кто запрещает? =)

Так вот я и запутался. Раньше оно просто работало а теперь как не пробую ничего не фурычит.

Тогда, видимо, моё не подойдёт, т. к. я там использую только systemd: требую (Requires=) монтирования целевой ФС, потом жду появления устройств из фиксированного списка и по мере появления их бэкаплю.

Спасибо буду копать дальше.

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

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

Конфиги чего?

Вообще мне надо rsync на определенную флешку по факту вставляния её в комп. Что юнит systemd там элементарнейший что правила udev не менее элементарные.

udev и s-d. Ну, может и элементраные. Тогда забей

бекап на флешку это как игра в рулетку

это может быть и не флешка, а внешний диск. либо несколько фшелек. сам я юзаю тупо cron определяющий наличие файла в примонтированном каталоге. удобно - для бекапа нужно всего лишь физически подключить нужный носитель

бекап на флешку это как игра в рулетку

Поясни.

зачем это все когда есть сеть и облака? я флешку последний раз держал в руках пару месяцев назад когда ставил ос на десктоп.

зачем это все когда есть сеть и облака?

В теме про запуск самодельных велосипедов при появлении нужных накопительных устройств посредством systemd/udev я срать хотел и на сеть и тем более на облака.

Если запускать скрипт прямо с правила udev, то он будет прибит как только udev закончит обработку события, и даже негде будет посмотреть, сработал ли скрипт, его stdout/sdterr и т.д. Поэтому намного удобней вызывать systemd сервис.

Я когда-то сделал подобное для автоматического запуска USB-Tethering при подключении Android смартфона, я думаю легко переделать для твоей задачи.

/etc/udev/rules.d/51-android.rules

SUBSYSTEM!="usb", GOTO="android_usb_rules_end"
LABEL="android_usb_rules_begin"
ATTR{product}=="ZP900S", ENV{adb_user}="yes"
ENV{adb_user}=="yes", MODE="0660", GROUP="usb"
ACTION=="add", ENV{adb_user}=="yes", TAG+="systemd", ENV{SYSTEMD_WANTS}="tether.service"
LABEL="android_usb_rules_end"

[Unit]
Description=Android USB Tethering

[Service]
Type=simple
ExecStart=/usr/local/bin/tether

# собственно сам скрипт
adb shell setprop persist.sys.usb.config rndis,adb
и т.д.

Если вдруг придется остановить сервис по udev-событию - тогда да, придется вручную дергать /usr/bin/systemctl --no-block stop tether.service с правила.

Я когда-то сделал подобное для автоматического запуска USB-Tethering при подключении Android смартфона, я думаю легко переделать для твоей задачи.

Ага ну вот примерно то же самое и мне надо. Просто надоело руками синхронизировать одни и те же файлы.

В любой момент я могу посмотреть systemctl status tether.

Это как раз понятно.

Если вдруг придется остановить сервис по udev-событию - тогда да, придется вручную дергать /usr/bin/systemctl --no-block stop tether.service с правила.

Ну выключить сервис только из-за того что устройства уже по факту нет? А через тот же udev на пропадание устройства выполнить команду не выйдет?

Вот смотрите раньше было относительно просто и понятно

Пытаюсь осилить то же самое сейчас

ням ням, вкусный кактус :)

А через тот же udev на пропадание устройства выполнить команду не выйдет?

Это делается через:

• TAG+="systemd" в udev (что заставляет systemd создать .device-юнит для этого устройства)
• BindsTo=%i.device и After=%i.device в systemd-юните (что заставляет systemd запускать юнит только после полной обработки добавления устройства, а также останавливать юнит при удалении устройства)

ням ням, вкусный кактус :)

Есть другие варианты я тебя внимательно слушаю. Нет? Ну так давайпокадосвидания.

Это делается через:

Вот почему и говорю что примеров надо :)

давайпокадосвидания

Ну нет :) Кактусопоедание я досмотрю до конца :)

С примерами небольшая лажа, т. к. судя по всему в udev нет такого спецификатора (типа %p или %k), который трансформировался бы в корректный путь к узлу устройства (чтобы его можно было бы передать как аргумент шаблонному systemd-юниту, а в самом юните сделать BindsTo=%i.device).

Написал в systemd-devel: http://lists.freedesktop.org/archives/systemd-devel/2014-July/021683.html

Как workaround, можно создать алиас через правило:

ATTR{name}=="My-Backup-Flash-Name", SYMLINK+="my-backup-flash", TAG+="systemd", ENV{SYSTEMD_WANTS}+="rsync-backup.service"

BindsTo=my-backup-flash

Не знаю. А где создаётся симлинк? Нужно BindsTo=<полный-путь-к-симлинку>.device.

Создается /dev/my-backup-flash. Если к нему в пару systemd создает юнит my-backup-flash.device, то можно сделать BindsTo=my-backup-flash.device

BindsTo=dev-my\x2dbackup\x2dflash.device, и да, это работает. Но костыль.

Ну нет :) Кактусопоедание я досмотрю до конца :)

О некактусоед не желаешь поделится своей мудростью? Но предостерегаю тебя сразу с вендовз/BSD* и прочими гейосями иди нафиг с такой мудростью. И да я ленивый и всё делать ручками знаю и умею но не поддерживаю поэтому тоже иди ка ты лесом.

Впрочем, данный способ является жопой, поскольку из номера USB-устройства на шине очень затруднительно получить путь к диску, который это устройство собой представляет.

А что здесь костылистого-то? Если нужно сразу несколько устройств, то можно создавать /dev/backup0, /dev/backup1 и т.д., и передавать номер как в юнит как параметр. Все подсистемы так и работают (/dev/input/mouse{0,1,..}, /dev/video{0,1}, .. - у них ведь тоже есть полные имена - /dev/bus/usb/XXX..). Unix-Way в чистом виде.

А тебе точно нужен udev? Если у тебя есть одна конкретная флешка, на которую нужно бэкапить (или заранее определённый набор флешек), то можно обойтись средствами systemd как такового.

Вообще, опиши исходную задачу. Такое ощущение, что мы решаем XY-проблему.

Из /dev/usb/XXX/YYY очень сложно получить /dev/sdXY.

А тебе точно нужен udev?

Не ну я вообще как бы исхожу из того что было раньше. До systemd был bash скрипто-велосипед и правило для udev этого хватало. Теперь я эту текущую схему вроде понял… Но одно дело понять а другое чтобы оно просто заработало. А по идее надо в то же самое правило udev что было раньше писать вызов не сразу велосипеда а юнита systemd которым и запускать велосипед. Появляется девайс радостный udev пинает юнит systemd а он пинает велосипед всё работает и все задействованы и вовлечены в общий процесс! Радость! Счастье! И всё такое… А на деле сильно много звеньев тоже не очень хорошо хотя вроде как по идее надо именно так.

Получить device path

udevadm info -q path -n /dev/my-backup-flash

offtopic: полагаю, анонимус уже начинает смеяться.

Ок. На самом деле, ничего не должно было сильно усложниться, т. к. systemd-юнит вполне может быть тупой прослойкой между udev и скриптом, в каковом случае вообще пофиг на то, что передавать параметром. Но хочется сделать по-нормальному, с BindsTo= (чтобы юнит останавливался при выдирании флешки) — и в этом случае уже нужно передавать корректный путь к устройству.

У тебя было правило на подсистему block или usb? Если второе, то я не совсем понимаю, как оно работало.

Ок. На самом деле, ничего не должно было сильно усложниться

Да это всё понятно.

У тебя было правило на подсистему block или usb? Если второе, то я не совсем понимаю, как оно работало.

Вообще было на block хотя там по сути разницы особо то и нет потому что задача была тупо отследить заданный девайс и пнуть самодельный велосипед.

Вот.

http://morrisjobke.de/2014/01/09/My-backup-strategy/

правило udev:

ACTION=="add", SUBSYSTEM=="block", ENV{ID_FS_LABEL}=="backup-*", TAG+="systemd", ENV{SYSTEMD_WANTS}+="backup@%k.service"

юнит systemd (backup@.service)

[Unit]
Description=Backup to device %i
BindsTo=dev-%i.device
After=dev-%i.device

[Service]
Type=oneshot
ExecStart=/etc/systemd/scripts/backup.sh /dev/%i
KillMode=control-group

Это по-прежнему немного костыльно, т. к. работает только потому, что %k для блочных устройств — это строка вида «sdXY», она не содержит не-алфавитных символов и эскейпить её не требуется. Но работает. Ответ от systemd-devel ждём.

Ответили в списке рассылки, указав, что проблема не нова. Решается через утилиту systemd-escape, которая сворачивает/разворачивает строки с escape последовательностями (вот только я саму утилиту не нашел, зато нашел веб-сервис). Предполагается использовать конструкцию навроде myservice@$(/usr/lib/systemd/systemd-escape %k).service в правилах udev.

Анонимус уже ржет вголос с этого кактусопоедания.

пилять! я мегалоялен к системд, но факты постепенно начинают напрягать даже меня. Самая мулька в том, что «нашел веб-сервис», а ведь systemd-escape действительно нет, например, в федоре20

Анонимус уже ржет вголос с этого кактусопоедания.

Тебя никто не держит можешь идти и ржать вместе с ним. Но это не изменит того факта что systemd в дефолте в подавляющем большинстве дистров. И лично мне насрать что именно будет запускать мой велосипед.

не понимаю ваших проблем сер, у меня были правила на центосе, тоже под флешку, я их перенес на арч положил в /etc/udev/... и они там все также успешно работают, не смотря на присутствие systemd

у меня были правила на центосе, тоже под флешку, я их перенес на арч положил в /etc/udev/... и они там все также успешно работают, не смотря на присутствие systemd

Ну и молодец сходи возьми конфетку.

А у меня всё было и всё работало потом был длииииииииинннннннныыыыыыый перерыв а сейчас ВНЕЗАПНО все что было раньше устарело и перестало работать. Засим надо сперва понять а как же оно сейчас для того что грамотно обновить то что были раньше. И проблема усложняется тем что в инторнетах море примеров разного времени и зачастую уже не актуальных.

Мы тут пробуем утилизировать фичу с BindsTo в systemd - привязать юнит к конкретному девайсу, чтобы скрипт автоматически завершался при отключении оного. Столкнулись с проблемами (передача device kernel name с udev в systemd и далее в скрипт node name), которые решаются через жуткие костыли.

systemd - синдром подростка у разработчиков

В попытках упростить да улучшить и без того простое да отлаженное наворотили кучу кастылей. Теперь внезапно выясняется что что-то по дороге сломалось. Хотели как лучше, но вышло ... *вздыхает*

Ещё нет. В systemd-216 запилили.

«Там» костылей нет. Костыли потребовались в данном конкретном случае. Идите учить матчасть, прежде чем излагать своё «авторитетное» мнение в провокационной формулировке.

Да, я уже прочёл. Значит, ждём или делаем как по приведённой мной ссылке — пока что работает.

простое да отлаженное

Это ты /sbin/hotplug назвал простым да отлаженным? Нет, спасибо.

Стоп: кажется, все срачи по поводу udev утихли лет пять назад.

У меня не так уж много практики и intelfx в чем-то прав, заявляя о моей некомпетентности, однако с предыдущей системой автозапуска (SysV) и udev у меня никогда проблем не было, в отличии от upstart`а, с которым я по сей день никак не освоюсь...

В общем тему закрыл. Предложенными способами можно пользоваться для запуска самодельных велосипедов для обработки конкретных устройств. Смежные вопросы у меня всё еще остались но это уже не для этой темы.