[РЕШЕНО] Автомонтирование CD/DVD через udev

ind.indeviral
это не отмонтирование я просто там много сточек написал)) оно папку umount создаёт))
KERNEL=="sr0", PROGRAM="/usr/bin/lsblk -dnro FSTYPE /dev/sr0",RESULT=="",RUN+="/usr/bin/mount /dev/sr0 /media/cdrom"
так понятнее)
Тоже не отдаёт диск, обратно лоток затягивает.

Но всё это не имеет отношения к моему вопросу. Я не спрашиваю, как можно сделать автомонтирования - я его уже сделал, и в первом посте привёл решение. Я спрашиваю, почему не срабатывают, вроде бы, правильные условия в неработающем правиле, приведённом в конце того же первого поста.
У меня в вашем правиле не срабатывает IMPORT{program} (но это может мой косяк быть)
А вообще:
1. lsblk не успевает ещё увидеть fs когда отрабатывает.
2. При вытаскивании диска правило выполняется два раза.
Ошибки в тексте-неповторимый стиль автора©
ind.indeviral
У меня в вашем правиле не срабатывает IMPORT{program} (но это может мой косяк быть)
У меня тоже. Вот в этом и вопрос - почему?
ind.indeviral
А вообще:
1. lsblk не успевает ещё увидеть fs когда отрабатывает.
2. При вытаскивании диска правило выполняется два раза.
Но со скриптом-то всё работает. При вставлении диска правило тоже вызывается дважды, и второй раз - как раз при обнаружении файловой системы.Тут не в логике дело, а в какой-то дурной ошибке парсинга.
akorop, как я уже писал в другой теме, в правило UDEV лучше не вставлять операции, которые могут затянуться, потому что UDEV имеет свойство убивать дочерние процессы по истечении довольно короткого таймаута. А операции с сидишником – и чтение параметров, и монтирование – очень даже могут затянуться, и вы это знаете.

Хороший способ запустить из UDEV какой-то затяжной процесс – вставить в правило команду типа systemctl start юнит@параметр.service , и уже в этот юнит вставлять запуск "долгоиграющих" команд или скриптов.
Natrio
akorop, как я уже писал в другой теме, в правило UDEV лучше не вставлять операции, которые могут затянуться, потому что UDEV имеет свойство убивать дочерние процессы по истечении довольно короткого таймаута. А операции с сидишником – и чтение параметров, и монтирование – очень даже могут затянуться, и вы это знаете.
Как-то упустил из виду, спасибо за напоминание. Но здесь не тот случай, поскольку скрипт прекрасно отрабатывает. И это понятно: второе событие change происходит, когда уже увиделась файловая система, так что особых тормозов mount не вызывает.
Тут явно что-то не то именно с парсингом вывода lsblk. А заменить lsblk на "проверенную" blkid нельзя - blkid вдвигает лоток, и, соответственно, не отдаёт диск.
akorop
Тут явно что-то не то именно с парсингом вывода lsblk
Каким ещё парсингом? Команда
lsblk -drno FSTYPE /dev/sr0
выводит одно-единственное слово, парсить нечего, в этом главное преимущество lsblk – ничего лишнего в выводе.
Вроде, разобрался. Точнее, догадываюсь.
Дело оказалось таки не в парсинге, а во времени, но весьма нетривиальным образом. Похоже, что какие-то действия по обнаружению файловой системы (или её отсутствия) делаются после всяких PROGRAM или IMPORT, но до RUN. И это не гонки при параллельном выполнении, а вполне детерминированный процесс. К такому выводу я пришёл после следующего эксперимента, в котором один и тот же скрипт получения файловой системы вызывается из PROGRAM и из RUN, а внутри скрипта ФС читается дважды, с задержкой между чтениями.
Правило udev:
UDEV!="sr0", GOTO="dvd_auto_mount_end"
ACTION!=="change", GOTO="dvd_auto_mount_end"
PROGRAM="/usr/local/bin/get_fs PGM"
RUN+="/usr/local/bin/get_fs RUN"
LABEL="dvd_auto_mount_end"
Скрипт /usr/local/bin/get_fs:
#!/bin/bash
T1=`date +"%T.%N "`
R1=`/usr/bin/lsblk -dnro FSTYPE /dev/sr0`
echo "$T1 get_fs $1 1 [$R1]"  >> /var/log/ccd.log
sleep 3
T2=`date +"%T.%N "`
R2=`/usr/bin/lsblk -dnro FSTYPE /dev/sr0`
echo "$T2 get_fs $1 2 [$R1]"  >> /var/log/ccd.log
echo -n $R2

Лог со вписанными руками пояснениями:
Вдвигаю лоток с диском:
18:07:01.459410818  get_fs PGM 1 []
18:07:04.465268230  get_fs PGM 2 []
18:07:05.747441012  get_fs RUN 1 [iso9660]
18:07:08.753899171  get_fs RUN 2 [iso9660]
Выдвигаю лоток с диском:
18:07:15.283436552  get_fs PGM 1 [iso9660]
18:07:18.289856912  get_fs PGM 2 [iso9660]
18:07:18.305546531  get_fs RUN 1 []
18:07:21.309287019  get_fs RUN 2 []
18:07:25.669058716  get_fs PGM 1 []
18:07:28.673059964  get_fs PGM 2 []
18:07:28.725507557  get_fs RUN 1 []
18:07:31.733833114  get_fs RUN 2 []
Ещё один лог, в котором sleep внутри get_fs исключён:
Вдвигаю лоток с диском:
18:05:02.674537072  get_fs PGM 1 []
18:05:02.677922402  get_fs PGM 2 []
18:05:03.965240705  get_fs RUN 1 [iso9660]
18:05:03.970551630  get_fs RUN 2 [iso9660]
Выдвигаю лоток с диском:
18:05:06.258080976  get_fs PGM 1 [iso9660]
18:05:06.260402415  get_fs PGM 2 [iso9660]
18:05:06.275754662  get_fs RUN 1 []
18:05:06.278382822  get_fs RUN 2 []
18:05:10.622085694  get_fs PGM 1 []
18:05:10.625660402  get_fs PGM 2 []
18:05:10.682122533  get_fs RUN 1 []
18:05:10.686187992  get_fs RUN 2 []
Получается, что задержка в 3 секунды внутри скрипта, вызванного из PROGRAM не меняет тип ФС (первый лог), а даже 15 мс между PROGRAM и RUN уже меняют тип (вторй эксперимент, выдвигание лотка).

Оргвывод: решение со скриптом, приведённое в первом посте, - единственно возможное. А попытки анализировать ФС внутри правила работают с предыдущим состоянием и, стало быть, ни на что не годны.
Это сейчас так. А после очередного обновления udev или не знаю уж чего ещё, может оказаться как раз наоборот.
 
Зарегистрироваться или войдите чтобы оставить сообщение.