How to avoid an absolute path to an executable in systemd?

Question

I have multiple different projects already containing Upstart services and am implementing the approach to symlink those services into /etc/init directly from a SVN working copy. Upstart provides embedded scripting in which I'm able to simply read the target of my symlink and execute additional scripts or the executable of the service itself. The important thing for my setup is only the following line:

cd "$(dirname "$(dirname "$(readlink "/etc/init/${UPSTART_JOB}.conf")")")"

This way I don't need to hard code any absolute path to my working copies, but simply rely on the symlink and some defined relative directory layout of my various projects. I would like to implement the same approach for systemd, but stick as much as possible to its suggested concepts, which seems to not support embedded scripts the way I formerly used.

I already know that systemctl enable /usr/local/.../someApp.service allows me to keep my service definition in the SVN working copy. The only thing I'm currently missing is properly adopting my readlink approach to not need to hard code an absolute path. I've read about specifiers already, but from my understanding they don't provide absolute paths and don't resolve symlinks.

Besides those, I'm able to directly execute shells with an additional command line and in theory embed my readlink approach there. But that looks ugly.

Another approach I have in mind is some system wide dispatcher script, I already have some system wide /usr/local/vendor, to which I could forward specifiers and which implements my readlink approach externally.

But is there something easier I'm missing? Something simple like the following, where %f would be the resolved symlink target:

ExecStart = %f/../../bin/someApp.pl

Which seems easier than the following examples:

ExecStart = /bin/sh -c "..."

ExecStart = /usr/local/vendor/systemd/dispatcher "%f"

Thanks!

Solution

No, systemd has no built-in feature for this.

Just as with Upstart, you'll have to call a shell.

Comments

[Thorsten Schöning]

Just wanted to write a bug report with my problem and found the following, so this is obviously the correct answer. If anyone wants a change, take part in the discussion: github.com/systemd/systemd/issues/6308