Отладка службы systemd
curl не является полноценным -браузером и, насколько мне известно, не поддерживает выполнение JavaScript. Он использует HTTP/FTP для получения файлов; это все. Если вы хотите провести тестирование функциональности, которая зависит от сценариев или других инструментов, которые не может затронуть голый HTTP-запрос, вам нужно будет изучить более глубокий -набор тестов, такой как Selenium.
Я обнаружил, что проблема заключалась в том, что мне не хватало /bin/bashв строке ExecStart=
поэтому мне нужно было изменить:
ExecStart=/usr/local/lib/throttle_daemon/throttle_daemon
-
ExecStart=/bin/bash /usr/local/lib/throttle_daemon/throttle_daemon
Мне также не хватало конфигурации тайм-аута, мне нужно было добавить:
StartLimitBurst=0
в мой раздел [Service], после чего моя программа работает, как и ожидалось.
Я также изменил WantedByна graphical.targetвместо multi.user.target, потому что я запускаю рабочий стол, и я чувствую, что уведомления будут падать, если я запущу их на терминале без x-сервера, но я не могу подтвердите это.
Если я не ошибаюсь, notify -send использует dbus для отправки уведомления. Во-первых, ваш сервис по умолчанию запускается от имени пользователя root, поскольку он является системным блоком (на основе пути, который вы указали в файле.service ). Во-вторых, если он должен работать от имени пользователя root, вам нужно убедиться, что notify-sendсможет получить доступ к сокету dbus сеанса вашего обычного пользователя. Обычно в современных дистрибутивах это/run/user/1000/bus(при условии, что идентификатор вашего пользователя равен 1000, см. id --userкак этот пользователь ).
Вы можете добавить это в свой юнит-файл:Environment=DBUS_SESSION_BUS_ADDRESS=unix:abstract=/run/user/1000/bus
Не совсем уверен, что это позволит notify-sendправильно отправить свое сообщение. Могут существовать политики (polkit или политики dbus ), которые запрещают другим пользователям общаться с программными интерфейсами, предоставляемыми сеансовым демоном dbus на сокете.