[Решено] Не получается выполнить команду rm, размещённой в unit'е systemd

Здравствуйте! При старте некоторого юнита (пусть будет unit), нужно почистить его каталог (folder), куда он пишет файлы (file), во время работы. Делаю так, в /etc/systemd/system/ создаю каталог unit.service.d, а в нём файл unit.conf с таким содержимым:


[Service]
ExecStartPre=/usr/bin/sh -c 'rm -r /var/lib/folder/*'

Это вызывает ошибку: sh[9576]: rm: невозможно удалить '/var/lib/folder/file': Отказано в доступе
Владелец каталога folder, unit, права 700.
ну как минимум rm -rf
По идее все должно работать … смущает только это
vladis
Владелец каталога folder, unit, права 700.
Проверь для начала удаление обычной директории, типа
ls /test
test.txt

PS - добавил в имеющийся юнит строчку с ExecStartPre= ... и создал /test/test.txt
cat /etc/systemd/system/webcam.service | grep Service -A 3
[Service]
Type=idle
ExecStartPre=/bin/rm -r /test
ExecStart=/home/vasek/.local/bin/webcam.sh
После reboot все сработало
ls /test
ls: невозможно получить доступ к '/test': Нет такого файла или каталога
Ошибки не исчезают с опытом - они просто умнеют
vasek
смущает только это
Что смущает? Пользователь unit имеет права на каталог folder 700, владелец и группа он же. Так я делал в начале, пишет что /usr/bin/rm: невозможно удалить '/var/lib/folder/*': Нет такого файла или каталога. Без ребута, просто перезапускаю тут же сервис и ошибка.
vladis
Что смущает?
Там много нюасов, в тонкости не вникал, так как сам это не использовал, но из того, что помнится:
- файлы, созданный в процессе работы сервиса, удаляются автоматически, если задать директорию запуска (что то типа RunDir, точно не помню)
- при необходимости нужно задавать и user и group и mode
- если, например, указывается что то типа ExecStartPre=/bin/rm …, а dir не существует, то будет ошибка … для исключения этого перед командой нужно прописывать знак -
… и др. … рекомендую посмотреть DOC … а что то советовать не зная процесс, нет смысла.

PS - если не найдешь DOC, посмотрю у себя в базе, что имеется на эту тему.
Ошибки не исчезают с опытом - они просто умнеют
Так как раз /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, который я и редактирую. Каталоги существуют, пользователя и группы в оригинальном юните нет, это да.
vladis
редактировал оригинальные юнит
Похоже что изменил что то существенное ... обычно изменения делают не значительные, а уж менять права вообще не приходится.
Пробуй применить debug (способов несколько) ... или делать изменения по этапно, небольшими кусками, если это возможно.

PS - непонятно почему используется /usr/lib/systemd/system .... как правило, для изменения или написания нового используется /etc/systemd/system
Ошибки не исчезают с опытом - они просто умнеют
Насколько понял в логах ничего крамольного нет.
Тогда можно попробовать увелить логирование до уровня debug … если сервис можно перезагрузить в работающей системе, то можно это осуществить и без перегрузки.
Можно попробовать 2 способа (надежды мало, но проверить стоит)
1. Увеличиваем логирование только при работе самого сервиса
sudo systemctl stop  проблемный.service
SYSTEMD_LOG_LEVEL=debug sudo systemctl start проблемный.service
2. Увеличиваем логирование всей системы
sudo systemd-analyze set-log-level debug
Проверяем
systemctl log-level
… и далее перезапускаем сервис
sudo systemctl stop  проблемный.service
sudo systemctl stаrt  проблемный.service
… и смотрим логи journal (лучше запустить заранее, используя journalctl -f)

Далее можно еще запустить systemd в тестовом режиме, типа такого
/usr/lib/systemd/systemd --test --system --log-level=debug > systemd-test.txt 2>&1
… и анализировать файл systemd-test.txt - смотрим или вытаскиваем из файла строки проблемный.service

Если результата нет (ничего не выявили), то придется использовать тяжелый инструмент - strace.
Ошибки не исчезают с опытом - они просто умнеют
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
Сам по себе юнит работает, не работает с моим добавлением, т.к. "отказано в доступе" в итоге вызывает сбой всего юнита.
vladis
я добавил эти изменения в /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
Не рекомендую использовать на постоянной основе способ, приведенный в указанной сылке (Drop-in файлы) - это не всегда работает.
PS - и редактируя таким способом есть нюанс - если unit содержал ExecStartPre, то сначала его нужно обнулить.
Пробуй обычный способ: скопировать нужный unit из /usr/lib/systemd/system/ в /etc/systemd/system/ … и внести нужные изменения.

PS - пояснение в части обнуления - как пример, изменил только ExecStart в [email protected]
cat /etc/systemd/system/[email protected]/override.conf
[Service]
 ExecStart=
# no login, no password
 ExecStart=-/sbin/agetty -a 'vasek' --noclear %I $TERM
Ошибки не исчезают с опытом - они просто умнеют
 
Зарегистрироваться или войдите чтобы оставить сообщение.