Почему ключ After в юните срабатывает до автомонтирования?

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

я бы навесил этот скрипт не на after automount, а на какой-нибудь PathExists=. Логика будет вроде та же самая, зато точно сработает

На нулевой взгляд — тебе, как минимум, нужен .mount, а не .automount. Юнит .automount считается запущенным сразу после того, как будет настроена точка автомонтирования.

Тоже голосую за удев. Системд юнит можно оставить, но запускать его как oneshot

может тупо добавить sleep 5 в питон скрипт, в начале?

может тупо добавить sleep 5 в питон скрипт, в начале?

Чуть ранее, в нулевом посте темы…

Кроме того, закомментировав функции работы с файлами, при помощи задержки в скрипте на Питоне и команды ls /flash я выяснил, что флешка не монтируется до тех пор, пока скрипт не будет выполнен до конца.

Нет. Задержка. Не. Помогает.

я бы навесил этот скрипт не на after automount, а на какой-нибудь PathExists=

Поменял в скрипте…

After=flash.automount

…на…

PathExists=/flash/

Не помогло. Всё также запускается мой скрипт на Питоне, начинает мигать светодиодами на Orange Pi One, а потом на so.makedirs() он пишет «No such device /flash/newfolder100500». При этом я устанавливаю внутри скрипта на Питоне задержку секунд на 5-10 и пока он не дошёл до so.makedirs(), я пытаюсь проверить монтирование флешки выполнением команды ls /flash. Пока скрипт ждёт, ls не отрабатывается. Пока скрипт висит на so.makedirs, также ls не отрабатывается. Как только я «прихлопываю» Питон командой sudo pkill -9 -f db_copy.py, так сразу ls /flash выдаёт содержимое флешки.

Может, конечно, где-нибудь какой-нибудь кэш не обновился после изменений в my_backup.service, но я повводил…

sudo systemctl daemon-reload
sudo systemctl restart local-fs.target
sudo systemctl stop my_backup.service
sudo systemctl enable my_backup.service
sudo systemctl start my_backup.service
sudo reboot

…а результат тот же.

На нулевой взгляд — тебе, как минимум, нужен .mount, а не .automount.

Я занёс в /etc/fstab/ запись…

UUID=0698-A3CF  /flash  vfat  noauto,nofail,x-systemd.automount,x-systemd.idle-timeout=15,x-systemd.device-timeout=15

В результате в списке юнитов появился flash.automount

Я выполняю команду…

systemctl list-units

…и там flash.automount на первой строчке.

Ничего похожего на flash.mount во всём списке юнитов нет.

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

На чём порекомендуете создавать демона «по-нормальному»: на pure C или на asm?

Я попробовал повторить Ваши действия. Кажется, действительно проблема в том, что модуль запускается слишком рано, до того как фактически выполнится монтирование, как и описал intelfx.
Замена .automount на .mount вроде как решила эту проблему.
Было

[Unit]
...
Requires=run-media-pelewin-ufdpw.automount
After=run-media-pelewin-ufdpw.automount
...
[Install]
WantedBy=run-media-pelewin-ufdpw.automount

Стало

[Unit]
...
Requires=run-media-pelewin-ufdpw.mount
After=run-media-pelewin-ufdpw.mount
...
[Install]
WantedBy=run-media-pelewin-ufdpw.mount

Хотя модуль run-media-pelewin-ufdpw.mount не отображается в списке

$sudo systemctl list-units | grep "ufdpw"
  run-media-pelewin-ufdpw.automount

Но остались другие проблемы - например, после ввода #systemctl start my_backup.service командная строка висит в ожидании (по всей видимости ожидает завершения работы модуля). Так что модуль всё равно выглядит недоработанным.

А с .automount кроме прочего была ещё проблема, что он завершался после однократного выполнения скрипта.

Флешка только для бэкапов? Если да, то к чёрту юниты - пиши скрипт сразу с монтированием.

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

Т.е. после появления в этой точке ФС? Что тогда может не работать?

Судя по логам схема нерабочая. Не очень понимаю, почему порядок событий в логах такой. Ещё у ТС какие-то опции монтирования в /etc/fstab странные, которые я тоже скопировал. Какие-то таймауты на 15 секунд - что они дают, интересно?

//запуск модуля
ноя 01 19:01:55 pwcomp sudo[2747]:  pelewin : TTY=pts/2 ; PWD=/etc/systemd/system ; USER=root ; COMMAND=/usr/bin/systemctl start my_backup.service
...
//скрипт, который должен запускаться только после подключения флешки запускается сразу же
ноя 01 19:01:55 pwcomp systemd[1]: Started My backup script trigger.
...
ноя 01 19:01:55 pwcomp long-test.sh[2752]: start backuping...
ноя 01 19:01:55 pwcomp systemd[1]: run-media-pelewin-ufdpw.automount: Got automount request for /run/media/pelewin/ufdpw, triggered by 2753 (ls)
ноя 01 19:01:55 pwcomp systemd[1]: Expecting device /dev/disk/by-uuid/7E51-4094...
...
ноя 01 19:02:10 pwcomp kernel: usb 1-4: new high-speed USB device number 4 using ehci-pci
...
ноя 01 19:02:10 pwcomp systemd[1]: Timed out waiting for device /dev/disk/by-uuid/7E51-4094.
ноя 01 19:02:10 pwcomp long-test.sh[2753]: ls: cannot open directory '/run/media/pelewin/ufdpw': No such device
ноя 01 19:02:10 pwcomp systemd[1]: Dependency failed for /run/media/pelewin/ufdpw.
ноя 01 19:02:10 pwcomp systemd[1]: run-media-pelewin-ufdpw.mount: Job run-media-pelewin-ufdpw.mount/start failed with result 'dependency'.
...
ноя 01 19:02:11 pwcomp kernel: usb 1-4: New USB device found, idVendor=13fe, idProduct=1f23, bcdDevice= 1.10
...
ноя 01 19:02:13 pwcomp kernel: sd 6:0:0:0: [sdc] Attached SCSI removable disk
...
ноя 01 19:02:15 pwcomp long-test.sh[2752]: continue backuping...
ноя 01 19:02:15 pwcomp systemd[1]: run-media-pelewin-ufdpw.automount: Got automount request for /run/media/pelewin/ufdpw, triggered by 2854 (ls)
ноя 01 19:02:15 pwcomp systemd[1]: Mounting /run/media/pelewin/ufdpw...
ноя 01 19:02:16 pwcomp systemd[1]: Mounted /run/media/pelewin/ufdpw.
//фактически закончено монтирование и виден вывод ls -l (total 3021264)
ноя 01 19:02:16 pwcomp long-test.sh[2854]: total 3021264

Замена .automount на .mount вроде как решила эту проблему.

Я поменял .automaunt на .mount и началось следующее. На вставку флешки скрипт начинает работу, но не делает бэкап. А вот если после этого в командной строке набрать, скажем, ls /flash, он отрабатывает как надо.

На Ask Ubuntu сказали, что automount в fstab монтирует устройство в папку только если к папке есть обращение. А потом, когда обращения нет N секунд отмонтирует на всякий случай устройство.

С одной стороны звучит правдоподобно, потому как с automount в fstab я могу работать с /flash из командной строки, но lsblk показывает, что MOUNTPOINT флешке не назначен. С другой, чем как не обращением к /flash я занимаюсь в питоновском скрипте? Повторюсь, скрипт отрабатывает как из командной строки (создаёт подпапку во /flash и копирует в неё файл БД), так и из юнита при обращении сторонней утилиты к /flash.

А с .automount кроме прочего была ещё проблема, что он завершался после однократного выполнения скрипта.

Это не баг, это фича ))) Обычный .mount у меня начинает дёргать скрипт по каждому чиху в сторону /flash. Кроме собственно вставки флешки. ))) Не помогает даже директива oneshot. С другой стороны мне от этого ни жарко, ни холодно. А вот то, что скрипт не отрабатывает на вставку - это проблема, да.

Флешка только для бэкапов?

Да

Если да, то к чёрту юниты - пиши скрипт сразу с монтированием.

Я спачала так и пытался. Через /etc/udev/rules.d. Но. Даже когда мне удалось вкорячить в rule выполнение команды mount (на её выполнение постоянно нехватало прав), никакое копирование не отработало . На StackOverflow сказали, что RUN из rule выполняется, во-первых, в каком-то своём пространстве имён и ему кажется, что он всё примонтировал, а на самом деле или ничего не примонтировалось или примонтировалось и тут же отмонтировалось самим демоном. Во-вторых, RUN из rule предусматривает выполнение быстрых операций типа логирования. И не предусматривает длительные операции вроде копирования больших файлов.

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

А что тут странного? Юнит загружен, устройство появилось, вызван скрипт-бэкапа, не увидел точки монтирования, завершился... И только после этого ядро опознало флешку и начало её монтировать.

Совершенно точно косяк в системд или юните с разрешением зависимостей и порядком действий.

З.Ы. ...и они постоянно мне твердят что достаточно просто открыть мануал и сделать так, как тим написано...

Флешка только для бэкапов? Да

Тогда можно сделать это не через системд а через удев. Он может выполнять команду/скрипт при появлении данного конкретного устройства. Но там теоретически сложнее, хотя с другой стороны должно быть без неопределённостей поведения.

когда мне удалось вкорячить в rule выполнение команды mount (на её выполнение постоянно нехватало прав)

Опции noauto,user в /etc/fstab и монтируется юзером по явной команде.

RUN из rule предусматривает выполнение быстрых операций типа логирования

Значит быстрой командой надо инициировать операцию в каком нибудь изолированном screen или подобном. Или systemctl с юнитом дёрнуть.

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

Не, тут я не смогу. Я знаю что такая возможность есть и видел реализацию флешки с файлом в роли ключа шифрования к диску, но сам таких правил не писал.

Что тогда может не работать?

Я даже не знаю, с чего начать. Всё?

Смешно смотреть, как о «совершенно точно косяках в системд» рассуждают те, кто этот системд видел только на картинках.

У тебя каша в голове. Без гораздо более вменяемого понимания принципов работы ядра/udev/autofs ты ничего работающего не добьёшься, а так и будешь играть в испорченный телефон между «Ask Ubuntu» и ЛОРом.

На аскубунту написали одно, на ЛОРе написали другое, я сделал третье, о боже мой, почему ничего не работает.

Сколько было восторженной шумихи с появлением ChatGPT, чуть ли не об отдельном разделе на ЛОРе шла речь, где будет отвечать ИИ четко и по существу, без привычной воды, и больше не нужны будут ‘кожаные мешки’. И вот, все куда-то пропало. Тишь да гладь. Похоже не справились ‘роботы’… (

Позабыты хлопоты,
Остановлен бег,
Вкалывают роботы,
Счастлив человек!

Мы кажется уже определились, что ваше «системд видел только на картинках» упирается в «ты его видел и он тебе не понравился».

Эта хреновина - каша, понять которую могут лишь избранные. ТС это ещё одно свидетельство того, что недостаточно просто открыть мануал и сделать так, как там написано. Это не работает.

Если можете просто помочь - помогите ему. В инете останется на 1 правильный вариант больше. Если нет - возможно моё предложение с костылём через udev в обход системд - более рабочий вариант.

Без гораздо более вменяемого понимания принципов работы ядра/udev/autofs

Видишь ли, в чём заковыка. В фильмах вроде «Фотоувеличение» или «Пинк Флойд: Стена» можно искать второй, третий слой смыслов, утончённо разбирать постановку кадра оператором, сравнивать контекст и подтекст и тому подобное. Эти фильмы для чего-то подобного и снимались.

А ЭВМ и ПО - это не произведения артхаусного искусства. Это рабочие инструменты. Они должны решать проблемы, а не создавать их.

Затраты времени на изучение глубинных принципов работы любого инструмента не должны превышать преимуществ, предоставляемых этим инструментом. А по хорошему, должны быть много меньше. Так-то в угаре глубинности можно и до ассемблера дойти и до СистемВерилога, на котором написан процессор.

Есть три простых факта:

1. lsblk показывает список дисковых устройств и точек их монтирования
2. запись в fstab может обеспечить автомонтирование флешки
3. но у монтируемой таким образом флешки в lsblk не будет отображать точка монтирования

Тут можно много и долго говорить «А это потому, что…» и «На самом деле, глубинное понимание принципов позволит…», но глядя непредвзятым взглядом я бы сказал следующее:

• практически вся индустрия IT - это о договорённостях. Здесь нет таких объективных природных явлений, как дождь, снег и извержение вулканов. И если такое популярное устройство, как флешка, появилось примерно четверть века назад, можно было бы уже концептуализировать данный факт. Можно было бы выделить подкласс съёмных накопителей и провести эту классификацию от ядра ОС до распоследних прикладных утилит. Ну а можно говорить «Вы не понимаете, в Unix 1971 года флешек не было, а потому…»

• если одна подсистема обеспечивает просмотр точек монтирования, а другая - автомонтирование, но автомонтированные диски не отображаются в первой подсистеме (причины абсолютно не важны) налицо несогласованность частей системы. Налицо факт, что как минимум при разработке одной из частей был применён «костыль».

«Глубинное понимание принципов работы» оправдано тогда, когда эти принципы стройно и непротиворечиво сформулированы во имя повышения удобства работы. Глубинно понимать принципы работы костыля - не нужно. Нужно лишь понять, что костыль - это костыль, он реально существует и единственным правильным решением будет ворячить свой поверх существующего.

udev в обход системд - более рабочий вариант

Как я писал выше, udev создаёт определённые трудности с самим монтированием.

У меня мысль гораздо пошлее ))) Запускать мой скрипт через crontab раз в минуту )))

Слишком уж пошлая мысь.

Слишком уж пошлая мысь.

Это погодите )))

• Я сейчас отполирую свой скрипт
• Попиарю его
• Люди, которым нужен бэкап и не нужно «Глубинное Понимание Исторических Причин Работы Костылей» начнут им пользоваться
• Скрипт войдёт в репозитории
• Появятся Опытные Пользователи Линукс, усматривающие в моём убогом скрипте Смыслы (именно так, с большой буквы и во множественном числе).
• И если скрипт будет не налезать на какие-нибудь части системы, а неофиты будут жаловаться, эти Опытные Пользователи Линукс будут уже относительно этого убогого скрипта рассказывать «Вы просто не понимаете глубинных механизмов его работы»

))))))

Короче )))

С crontab всё получилось! Там только пара моментов в питоновском скрипте.

Во-первых, нужна система, которая отследит, что

• в системе не было флешки (точнее пути /flash), а теперь он появился
• в системе есть флешка и на неё уже был сделан бэкап
• в системе есть флешка и бэкап идёт прямо сейчас
• в системе была флешка с записанным бэкапом, но теперь её нет

Всё это я делаю путём записи и проверки соответствующей строчки в дополнительном файле /my_folder/db_copy_mark.txt

Во-вторых кронтаб запускает скрипт не чаще одного раза в минуту. Ну ничего, в понедельник переделаю на таймерах Системд и всё залетает ))))

Задача, можно сказать, с блеском выполнена )))) Буду всем советовать это решение. А тут говорили «Нужно глубинное изучение! нужно глубинное изучение!» ))))

Да нет, ни во что оно не упирается. Только в твою безграмотность и брехливость ;)

Внятной причины почему зависимость И .mount И .automount должна срабатывать ДО собственно монтирования так и не предоставлено. Как и ссылки на док, где это описано. Как и правильного варианта юнита аж из 4-х строк в очевидно самом типовом варианте. Всё прочее - брехня. В итоге кривой костыль опять оказался лучше.

З.Ы. у меня появилось подозрение, что мои попытки самостоятельно примонтировать tmpfs в /tmp законились полным провалом по той же самой причине.

Вы просто не понимаете глубинных механизмов ))) Да, вся эта тряхомундия не работает как надо. Но если бы вы потратили пол года на её изучение, вы бы поняли, что она суперлогично не работает как надо. )))))

потому-что это системд, от слова дупа