Bug 35387 - RFE: first argument to ExecStart= does not accept env var or %I style resolution
Summary: RFE: first argument to ExecStart= does not accept env var or %I style resolution
Status: NEW
Alias: None
Product: systemd
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: All Linux (All)
: medium normal
Assignee: Lennart Poettering
QA Contact:
URL:
Whiteboard:
Keywords:
: 53697 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-03-17 06:31 UTC by Michael Stapelberg
Modified: 2015-05-02 14:51 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Attachments
sample service file, start works, stop doesn’t (629 bytes, application/octet-stream)
2011-03-17 06:31 UTC, Michael Stapelberg
Details

Description Michael Stapelberg 2011-03-17 06:31:01 UTC
Created attachment 44544 [details]
sample service file, start works, stop doesn’t

I have attached the file postgresql@.service which uses %I to replace the version (postgresql@9.0.service) in paths.

Starting the service works due to using sh -c, but stopping the service via calling /usr/lib/postgresql/%I/bin/pg_ctl directly does not work. stracing systemd reveals that the command path itself does not get replaced while ARGV gets replaced:

[pid  4151] execve("/usr/lib/postgresql/%I/bin/pg_ctl", ["/usr/lib/postgresql/9.0/bin/pg_ctl", "stop", "-m", "fast", "-s", "-w", "-t", "20"], ["init=/bin/systemd", "BOOT_IMAGE=/vmlinuz-2.6.38-4", "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin", "PWD=/", "rootmnt=/root", "LANG=C", "MAINPID=4138", "HOME=/var/lib/postgresql", "LOGNAME=postgres", "USER=postgres", "PGDATA=/var/lib/postgresql/%I/main"]) = -1 ENOENT (No such file or directory)

When using /bin/sh -c 'exec …', it works correctly.

The same applies to the Environment= setting.
Comment 1 Lennart Poettering 2011-03-29 14:38:35 UTC
Yes, we require a proper path to be used as first argument of ExecStart= and friends. This is documented in systemd.service(5) if you have a look.

We enforce this in order to make things easier for SELinux. It's unlikely that we can change this.

I'll leave the bug open, to track things and because this is likely to be reported more often in the future.
Comment 2 Oliver Leonhardt 2012-01-03 02:05:30 UTC
I've read systemd.service(5) regarding the first argument of ExecStart and I can imagine that it makes things easier for SELinux.

Nevertheless, I agree with Michael that this would be a very useful feature. According to what I've read on the Internet, others would be happy to see such a feature as well ( http://permalink.gmane.org/gmane.linux.suse.opensuse.devel/35016 ).

Maybe such a feature could be manually enabled in systemd.conf. The default could be no/off/0 in order to work with SELinux out of the box.

In my case I'm running multiple instances of /usr/bin/Xvfb and I would like to sort out /var/log/messages according to the $programname. Therefore I would execute Xvfb via a symlink for each instance.

If I use Michael's suggestion with /bin/sh the $programname for every instance is always (not very surprisingly) "sh".

And the same happens if I use ExecStart=/sbin/startproc /usr/bin/Xvfb_%I and Type=forking.

I came in contact with systemd when I've upgraded to OpenSuSE 12.1 and until now I'm quite happy with it. It's quite an improvement compared to the situation in the past when I had to copy /etc/init.d/skeleton.compat and get rid of "FOO" first... Keep up the good work!
Comment 3 Lennart Poettering 2012-09-13 18:04:18 UTC
*** Bug 53697 has been marked as a duplicate of this bug. ***
Comment 4 Tom Prince 2013-02-18 17:32:42 UTC
This would be particularly useful for user instances of systemd, so that the same unit files can be used on multiple machines, with possibly different usernames/home directories.

I'm not sure how not substituting makes things easier for SELinux. Wouldn't it make sense to simply do the SELinux checks after making substitutions?
Comment 5 Marc Haber 2015-05-02 14:51:34 UTC
I also agree that this would be useful. I see that the behavior is documented,  but it is still a surprise.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.