| vladis |
|
|
Темы:
3
Сообщения:
19
Участник с: 21 января 2020
|
Здравствуйте! При старте некоторого юнита (пусть будет unit), нужно почистить его каталог (folder), куда он пишет файлы (file), во время работы. Делаю так, в /etc/systemd/system/ создаю каталог unit.service.d, а в нём файл unit.conf с таким содержимым:Это вызывает ошибку: sh[9576]: rm: невозможно удалить '/var/lib/folder/file': Отказано в доступе Владелец каталога folder, unit, права 700. |
| grayich |
|
|
Темы:
233
Сообщения:
2243
Участник с: 08 января 2009
|
ну как минимум rm -rf |
| vasek |
|
|
Темы:
47
Сообщения:
11819
Участник с: 17 февраля 2013
|
По идее все должно работать … смущает только этоvladisПроверь для начала удаление обычной директории, типа PS - добавил в имеющийся юнит строчку с ExecStartPre= ... и создал /test/test.txt cat /etc/systemd/system/webcam.service | grep Service -A 3 ls /test
Ошибки не исчезают с опытом - они просто умнеют
|
| vladis |
|
|
Темы:
3
Сообщения:
19
Участник с: 21 января 2020
|
vasekЧто смущает? Пользователь unit имеет права на каталог folder 700, владелец и группа он же. Так я делал в начале, пишет что /usr/bin/rm: невозможно удалить '/var/lib/folder/*': Нет такого файла или каталога. Без ребута, просто перезапускаю тут же сервис и ошибка. |
| vasek |
|
|
Темы:
47
Сообщения:
11819
Участник с: 17 февраля 2013
|
vladisТам много нюасов, в тонкости не вникал, так как сам это не использовал, но из того, что помнится: - файлы, созданный в процессе работы сервиса, удаляются автоматически, если задать директорию запуска (что то типа RunDir, точно не помню) - при необходимости нужно задавать и user и group и mode - если, например, указывается что то типа ExecStartPre=/bin/rm …, а dir не существует, то будет ошибка … для исключения этого перед командой нужно прописывать знак - … и др. … рекомендую посмотреть DOC … а что то советовать не зная процесс, нет смысла. PS - если не найдешь DOC, посмотрю у себя в базе, что имеется на эту тему.
Ошибки не исчезают с опытом - они просто умнеют
|
| vladis |
|
|
Темы:
3
Сообщения:
19
Участник с: 21 января 2020
|
Так как раз /usr/bin/sh -c 'rm -r /var/lib/folder/*' приводит к другой ошибке, из которой следует что файлы для удаления видны, но доступа нет. К тому же я как бы редактировал оригинальные юнит, ведь файл изменяемой части находится в /etc/systemd/system/unit.service.d/ это значит что это одно и тоже что лежит в /usr/lib/systemd/system/unit.service и всё что там есть, справедливо и для /etc/systemd/system/unit.service.d/unit.conf, который я и редактирую. Каталоги существуют, пользователя и группы в оригинальном юните нет, это да. |
| vasek |
|
|
Темы:
47
Сообщения:
11819
Участник с: 17 февраля 2013
|
vladisПохоже что изменил что то существенное ... обычно изменения делают не значительные, а уж менять права вообще не приходится. Пробуй применить debug (способов несколько) ... или делать изменения по этапно, небольшими кусками, если это возможно. PS - непонятно почему используется /usr/lib/systemd/system .... как правило, для изменения или написания нового используется /etc/systemd/system
Ошибки не исчезают с опытом - они просто умнеют
|
| vasek |
|
|
Темы:
47
Сообщения:
11819
Участник с: 17 февраля 2013
|
Насколько понял в логах ничего крамольного нет. Тогда можно попробовать увелить логирование до уровня debug … если сервис можно перезагрузить в работающей системе, то можно это осуществить и без перегрузки. Можно попробовать 2 способа (надежды мало, но проверить стоит) 1. Увеличиваем логирование только при работе самого сервиса sudo systemd-analyze set-log-level debug Проверяем systemctl log-level … и далее перезапускаем сервис Далее можно еще запустить systemd в тестовом режиме, типа такого Если результата нет (ничего не выявили), то придется использовать тяжелый инструмент - strace.
Ошибки не исчезают с опытом - они просто умнеют
|
| vladis |
|
|
Темы:
3
Сообщения:
19
Участник с: 21 января 2020
|
vasekПохоже я плохо объяснил. Права я никакие не менял, редактировал юнит, способом, который в итоге по пути /etc/systemd/system/ добавляет дополнительный конфиг к оригинальному. Т.е. допустим оригинальный юнит тут /usr/lib/systemd/system/unit.service. Я добавляю свои изменения, которые сообщил в первом посте, чтобы всё работало, как будто бы это unit.service, я добавил эти изменения в /etc/systemd/system/unit.service.d/unit.conf. Вот пример, подобного редактирования: https://wiki.archlinux.org/title/Systemd_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9)#Drop-in_%D1%84%D0%B0%D0%B9%D0%BB%D1%8B Сам по себе юнит работает, не работает с моим добавлением, т.к. "отказано в доступе" в итоге вызывает сбой всего юнита. |
| vasek |
|
|
Темы:
47
Сообщения:
11819
Участник с: 17 февраля 2013
|
vladisНе рекомендую использовать на постоянной основе способ, приведенный в указанной сылке (Drop-in файлы) - это не всегда работает. PS - и редактируя таким способом есть нюанс - если unit содержал ExecStartPre, то сначала его нужно обнулить. Пробуй обычный способ: скопировать нужный unit из /usr/lib/systemd/system/ в /etc/systemd/system/ … и внести нужные изменения. PS - пояснение в части обнуления - как пример, изменил только ExecStart в getty@.service cat /etc/systemd/system/getty@tty1.service.d/override.conf
Ошибки не исчезают с опытом - они просто умнеют
|