У меня есть несколько различных проектов, уже содержащих сервисы Upstart, и я внедряю подход, чтобы связать эти сервисы в /etc/init напрямую из рабочей копии SVN. Upstart предоставляет встроенные сценарии, в которых я могу просто прочитать цель моей символической ссылки и выполнить дополнительные сценарии или исполняемый файл самой службы. Для моей настройки важна только следующая строка:
cd "$(dirname" $(dirname "$(ссылка для чтения"/etc/init/$‹UPSTART_JOB‹.conf ")")")"
Таким образом, мне не нужно жестко кодировать какой-либо абсолютный путь к моим рабочим копиям, я просто полагаюсь на символическую ссылку и некоторую определенную относительную компоновку каталогов моих различных проектов. Я хотел бы реализовать тот же подход для systemd, но в максимально возможной степени придерживаться предложенных им концепций, которые, кажется, не поддерживают встроенные скрипты так, как я использовал ранее.
Я уже знаю, что systemctl enable /usr/local/.../someApp.service позволяет мне сохранить определение службы в рабочей копии SVN. Единственное, чего мне сейчас не хватает, - это правильного принятия моего подхода readlink чтобы не нужно было жестко кодировать абсолютный путь. Я уже читал о спецификаторах , но, насколько я понимаю, они не предоставляют абсолютные пути и не разрешают символические ссылки.
Кроме того, я могу напрямую запускать оболочки с помощью дополнительной командной строки и теоретически встраивать туда свой подход readlink . Но это выглядит некрасиво.
Другой подход, который я имею в виду, - это какой-то общесистемный скрипт диспетчера, у меня уже есть какой-то общесистемный /usr/local/vendor , которому я мог бы пересылать спецификаторы и который реализует мой подход readlink извне.
Но есть ли что-то более простое, что мне не хватает? Что-то простое, например, следующее, где %f будет разрешенной целью символической ссылки:
ExecStart =% f/../../bin/someApp.pl
Что кажется проще, чем в следующих примерах:
ExecStart = /bin /sh -c "..."
ExecStart = /usr /local /vendor /systemd /dispatcher "% f"
Спасибо!