the provided tvheadend.service file contains ExecStart=/usr/bin/tvheadend -p /run/tvheadend/tvheadend.pid -c ${TVHEADEND_CONFIG} ${TVHEADEND_OPTIONS} which doesn't work, as the environment variables aren't expanded, but executed as is. to expand variables in systemd service Exec... lines, the command needs to be wrapped in sh -c '...' Reproducible: Always
Created attachment 711681 [details, diff] proposed patch wrap ExecStart in /bin/sh -c '...'
Actually, the problem is the {}, expands fine if just $VAR and then don't need to wrap through /bin/sh gave it a quick try by removing {} and it's running as such: tvheade+ 113207 10.0 0.2 414696 26468 ? Ssl 13:10 0:00 /usr/bin/tvheadend -p /run/tvheadend/tvheadend.pid -c /var/lib/tvheadend I guess related to bug #690120
Yes, you're right. Just removing {} is enough, no need for sh -c "..."
Created attachment 711858 [details, diff] proposed patch
I think it should be: ExecStart=/usr/bin/tvheadend -p /run/tvheadend/tvheadend.pid -c ${TVHEADEND_CONFIG} $TVHEADEND_OPTIONS ${FOO} is treated as one argument whereas $FOO is split. We don't want TVHEADEND_CONFIG to be split. Agreed? I don't know whether this will fix bug #690120, it wasn't clear what the actual problem was there. Having both Type=simple with PIDFile is odd but I don't want to change it to Type=forking if it's otherwise working for you.
I agree with your opinion on what needs to be split and what not, but it seems systemd behaves a little bit strange here: tvheadend.service is like this: # /etc/systemd/system/tvheadend.service.d/override.conf [Service] ExecStart= ExecStart=/usr/bin/tvheadend -p /run/tvheadend/tvheadend.pid -c ${TVHEADEND_CONFIG} $TVHEADEND_OPTIONS firstly /etc/conf.d/tvheadend: [...] # Path to Tvheadend config. TVHEADEND_CONFIG="/var/lib/tvheadend" # Other options you want to pass to Tvheadend. TVHEADEND_OPTIONS="" result: ● tvheadend.service - tvheadend Loaded: loaded (/lib/systemd/system/tvheadend.service; enabled; vendor preset: disabled) Drop-In: /etc/systemd/system/tvheadend.service.d └─override.conf Active: active (running) since Sun 2021-05-30 13:05:53 CEST; 3s ago Main PID: 100653 (tvheadend) Tasks: 31 (limit: 38314) Memory: 54.2M CGroup: /system.slice/tvheadend.service └─100653 /usr/bin/tvheadend -p /run/tvheadend/tvheadend.pid -c /var/lib/tvheadend secondly /etc/conf.d/tvheadend: [...] # Path to Tvheadend config. TVHEADEND_CONFIG="/var/lib/tvheadend" # Other options you want to pass to Tvheadend. TVHEADEND_OPTIONS="--debug" result: ● tvheadend.service - tvheadend Loaded: loaded (/lib/systemd/system/tvheadend.service; enabled; vendor preset: disabled) Drop-In: /etc/systemd/system/tvheadend.service.d └─override.conf Active: activating (auto-restart) since Sun 2021-05-30 13:07:26 CEST; 4s ago Process: 101122 ExecStart=/usr/bin/tvheadend -p /run/tvheadend/tvheadend.pid -c ${TVHEADEND_CONFIG} $TVHEADEND_OPTIONS (code=exited, status=0/SUCCESS) Main PID: 101122 (code=exited, status=0/SUCCESS) as you see, if TVHEADEND_OPTIONS is something else than empty string, this breaks. seems a little strange from systemd for me...
turns out, this is independent of {} or not. I will try to investigate this in systemd, but for now, the only working solution seems to be to wrap the command line in sh -c "...", like in my first patch.
hmm, according to https://www.freedesktop.org/software/systemd/man/systemd.service.html#Command%20Lines , you are right. this should work as you described, just that it doesn't, at least for me. i tried also a small example service, with a env file and using both kinds of variables. And this works. Just tvheadend is problematic...
umpf..., turns out, this is tvheadends fault. Though tvheadend --help shows, there is a --debug option, it doesn't recognize it, and exits and displays the help page. I used --debug here, just to test it, as i assumed, this wouldn't change much in the behavior. problem is, --debug just doesn't work... Using a different cli option works. So conclusion: Change ${TVHEADEND_OPTIONS} to $TVHEADEND_OPTIONS and leave ${TVHEADEND_CONFIG} as it is.
You probably have to enable USE=debug! 😆 Anyway, thanks, I'll proceed with that.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=de8d29d5038faa33c3bdb099df5192abc89f2172 commit de8d29d5038faa33c3bdb099df5192abc89f2172 Author: James Le Cuirot <chewi@gentoo.org> AuthorDate: 2021-05-30 14:39:44 +0000 Commit: James Le Cuirot <chewi@gentoo.org> CommitDate: 2021-05-30 14:39:44 +0000 media-tv/tvheadend: Fix variable handling in systemd service file Closes: https://bugs.gentoo.org/792456 Package-Manager: Portage-3.0.19, Repoman-3.0.3 Signed-off-by: James Le Cuirot <chewi@gentoo.org> media-tv/tvheadend/files/tvheadend.service | 2 +- .../tvheadend/{tvheadend-4.2.8-r1.ebuild => tvheadend-4.2.8-r2.ebuild} | 0 2 files changed, 1 insertion(+), 1 deletion(-)
(In reply to James Le Cuirot from comment #10) > You probably have to enable USE=debug! 😆 > > Anyway, thanks, I'll proceed with that. Yeah, might be, but when an exectuable tells me, it has a flag, then I would expect, that it's also useable. It's not that hard to change --help output depending on configure options
And thanks for fixing!
This made me have a closer look given I rarely see conf.d being used in systemd units, and there's even prohibition in: https://wiki.gentoo.org/wiki/Project:Systemd/Ebuild_policy Users notably have access to `systemctl edit` to change defaults without a configuration file. Not that I'm all that familiar with systemd outside of a VM I keep for testing.
yeah, you are right. it's quite unusual to use a environment file in /etc/conf.d/. the more common place is /etc/default/, I think. But for now 1) it works and 2) is a different topic :) (In reply to Ionen Wolkens from comment #14) > This made me have a closer look given I rarely see conf.d being used in > systemd units, and there's even prohibition in: > https://wiki.gentoo.org/wiki/Project:Systemd/Ebuild_policy > > Users notably have access to `systemctl edit` to change defaults without a > configuration file. > > Not that I'm all that familiar with systemd outside of a VM I keep for > testing.
