Большая тайна, большое и светлое волшебство происходит, когда добровольцы объединяются для творения чего-то всем нужного, и, хотя бы немножечко, вечного.

Почему-то от этого чаще солнце выглядывает из-за облаков и очень хочется жить.

Правила и обычаи

Загадочное поведение udev

Загадочное поведение udev

Задумал сделать freemedia для uird. Идея в том, чтоб uird после подключения модулей из RAM размонтировал источники, генерил для каждого отмонтированного раздела скрипты, которые при запуске подключат  раздел в ту же точку монтирования с теми же параметрами. А также создавал правило udev, которое сработает при появлении отмонтированного диска и запустит эти скрипты.
С размонтированием и скриптами все ок. Если после загрузки вытащить флешку, вставить обратно и запустить вручную скрипты все монтируется на место и сохранение с machines работает. А вот с udev загадка на загадке.
Первое. Не всегда срабатывает выбор устройства по серийнику. То есть ENV{ID_SERIAL}== может сработать, а может и нет. Обойти можно перенеся проверку в скрипты. По uuid например.
Второе. И самое странное. Если правило таки сработало и скрипты запустились начинаются форменные чудеса. Точки монтирования создаются. Ошибок в логах нет. Если выхлоп ошибок каждой строчки скрипта писать в файл - файл будет пустым. В dmesg сообщения о монтировании разделов. Но. В proc/mounts ничего нового, и в точках монтирования пусто. Ничего не смонтировано. Если в скрипты добавить проверку типа ls /точка_монтирования > файл.log в файле будет список файлов из корня раздела. Если добавить cat /proc/mounts > лог, в логе будут новые строчки о монтировании. А также все предыдущие монтирования с udev. Но из системы ничего этого не видно. Ощущение, что udev работает где-то в чруте.
Есть идеи?
Обойти второй косяк тоже можно. Если в правиле вместо RUN+="скрипт" писать RUN+="/usr/bin/at -f /путь/скрипт now". Жесть какой костыль, но работает. Правда демон atd еще предварительно запустить надо sad Вот не знаю как быть. Костыль на костыле получается smile
Хорошо бы победить udev.

MagOS-Чат http://chat.magos-linux.ru
MagOS-Загрузки http://files.magos-linux.ru/upload
MagOS-Торренты http://tracker.magos-linux.ru

betcher
Александр
магистр-волшебник
ranks
useravatar
Offline
2604 Сообщений
Мужчина 
Администратор отключил публичную отправку сообщений

Re: Загадочное поведение udev

Простые примеры если кто проверить хочет.
MagOS user # cat /run/udev/rules.d/00.rules
KERNEL=="sd*", ACTION=="add", RUN+="/usr/bin/at -f /memory/mountsda4

MagOS user # cat /memory/mountsda4
#!/bin/bash
PATH=/bin:/sbin:/usr/bin:/usr/lib/magos/scripts
mkdir /mnt/sda4
mount /dev/sda4 /mnt/sda4
mdialog --msgbox "скрипт запустился"

udevadm test /sys/block/sda
посмотреть события udev связанные с /dev/sda  в том числе, какие скрипты запустятся, и тот самый ID_SERIAL
udevadm control -R
перечитать правила (вроде и без этого должно работать)
udevadm trigger -c add сымитировать подключение устройств (надо если проверяете с винтом, его как флешку воткнуть/вытащить не получится)

P.S. с приведенным правилом скрипт запустится несколько раз. На диск и на каждый раздел.
Чтоб запустилось только раз можно добавить ENV{DEVTYPE}=="disk", это в отличии от id_serial вроде всегда срабатывает.

MagOS-Чат http://chat.magos-linux.ru
MagOS-Загрузки http://files.magos-linux.ru/upload
MagOS-Торренты http://tracker.magos-linux.ru

betcher
Александр
магистр-волшебник
ranks
useravatar
Offline
2604 Сообщений
Мужчина 
Администратор отключил публичную отправку сообщений

Re: Загадочное поведение udev

Еще, кстати, одна загадка. Если в machines есть правило в /etc/udev/rules.d/. То после загрузки можно сколь угодно менять значение в RUN этого правила, udev тупо будет запускать то что было записано изначально. Даже после udevadm control -R и даже после systemctl restart udev.
Короче весело провел несколько вечеров sad(((((

MagOS-Чат http://chat.magos-linux.ru
MagOS-Загрузки http://files.magos-linux.ru/upload
MagOS-Торренты http://tracker.magos-linux.ru

betcher
Александр
магистр-волшебник
ranks
useravatar
Offline
2604 Сообщений
Мужчина 
Администратор отключил публичную отправку сообщений

Re: Загадочное поведение udev

betcher написал(а):

Еще, кстати, одна загадка. Если в machines есть правило в /etc/udev/rules.d/. То после загрузки можно сколь угодно менять значение в RUN этого правила, udev тупо будет запускать то что было записано изначально. Даже после udevadm control -R и даже после systemctl restart udev.

https://wiki.archlinux.org/index.php/ud … 0.B8.D0.BB
в этом вики написано что нужно выполнить udevadm control --reload-rules и udevadm trigger

betcher написал(а):

Второе. И самое странное. Если правило таки сработало и скрипты запустились начинаются форменные чудеса. Точки монтирования создаются. Ошибок в логах нет. Если выхлоп ошибок каждой строчки скрипта писать в файл - файл будет пустым. В dmesg сообщения о монтировании разделов. Но. В proc/mounts ничего нового, и в точках монтирования пусто. Ничего не смонтировано. Если в скрипты добавить проверку типа ls /точка_монтирования > файл.log в файле будет список файлов из корня раздела. Если добавить cat /proc/mounts > лог, в логе будут новые строчки о монтировании. А также все предыдущие монтирования с udev. Но из системы ничего этого не видно. Ощущение, что udev работает где-то в чруте.
Есть идеи?

M3-desk configs # grep /media /proc/mounts
tmpfs /media tmpfs rw,relatime,size=1024k 0 0
может это как-то мешает? папка создаётся под tmpfs и туда подключается устройства, а /media перекрывает?

Стяжи мир в себе и будут иметь мир с тобою небо и земля.
Исаак Сирский

МихаилZ
хранитель
ranks
useravatar
Offline
3243 Сообщений
Мужчина 
Администратор отключил публичную отправку сообщений

Re: Загадочное поведение udev

udevadm control --reload-rules это тоже, что udevadm control -R а триггер это эмуляция событий, например втыкания флешки. По второму пункту не понял, еще пару раз прочитаю smile

MagOS-Чат http://chat.magos-linux.ru
MagOS-Загрузки http://files.magos-linux.ru/upload
MagOS-Торренты http://tracker.magos-linux.ru

betcher
Александр
магистр-волшебник
ranks
useravatar
Offline
2604 Сообщений
Мужчина 
Администратор отключил публичную отправку сообщений

Авторизация