Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#30080 - [transmission-cli] add systemd service file

Attached to Project: Arch Linux
Opened by Marius (65kid) - Wednesday, 30 May 2012, 16:57 GMT
Last edited by Tom Gundersen (tomegun) - Monday, 20 August 2012, 13:58 GMT
Task Type Feature Request
Category Packages: Extra
Status Closed
Assigned To Ionut Biru (wonder)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


Please add the attached systemd service file to the transmission-cli package.

This service file does not respect /etc/conf.d/transmissiond because using an environment variable for User= doesn't seem to be supported by systemd. Specifying the user via @ imho makes more sense anyway and whoever wants to edit the settings can use the web interface, edit settings.json or copy the service file to /etc/systemd/system and edit ExecStart=.

upstream doesn't really seem to want to add this:
This task depends upon

Closed by  Tom Gundersen (tomegun)
Monday, 20 August 2012, 13:58 GMT
Reason for closing:  Implemented
Comment by Tom Gundersen (tomegun) - Friday, 01 June 2012, 11:29 GMT
Is running several occurrences of transmission at the same time a common thing to do? If so, is the thing that always distinguishes them from each other that they are run as different users?

If the answer to either of these questions is "no", then I don't think this service is correct.

I'd much rather just ship the simple transmission-daemon.service from the bugtracker you linked to. But obviously it should be renamed "transmission.service".

Let's keep things simple ;-)
Comment by Tom Gundersen (tomegun) - Friday, 01 June 2012, 12:19 GMT
I commented on the upstream ticket, and suggested my own service file there :)
Comment by Marius (65kid) - Friday, 01 June 2012, 16:33 GMT
I don't see your comment on the upstream ticket yet. comments are reviewed before there are visible on the transmission bugtracker...

anyway: no, running several transmission instances is obviously not something you would usually do and I understand that therefore using @ doesn't necessarily make sense. But how should the user be defined then? I would be fine to hardcode "User=transmission", but in that case the transmission-cli package should actually create that user, otherwise the service file wouldn't work out of the box. or would this not be considered a problem?

IMHO the best would be

...but this doesn't work because systemd doesn't allow environment variables in User=. :(
Comment by Tom Gundersen (tomegun) - Friday, 01 June 2012, 20:30 GMT
Yeah, my comment is taking its time before arriving (once it does I'll copy my suggestion here).

Essentially I think it would make the most sense if the package create a transmission:transmission (system)user/group, create the correct dir in /var/lib with the correct permissions and if nothing else is configured start transmission as this user.

If you want to use a regular user, I guess you might as well run transmission from your user session, or make a copy of the service file an configure it as you want. However, by default I think we should just have a simple service that does something sensible without further configuration.

We'll see what upstream has to say though...
Comment by Marius (65kid) - Friday, 01 June 2012, 20:41 GMT
ok, that makes sense. I assume we then set /var/lib/transmission/ as the transmission user $HOME? Then we wouldn't have to specify -g on ExecStart as in the original transmission-daemon.service in the upstream bug report.
Comment by Marius (65kid) - Thursday, 12 July 2012, 17:09 GMT
still no reaction upstream, and I don't really expect one anytime soon. can we add the service file to the package?
Tom's suggestions on the bugtracker look good to me, there is just still the question left if Type=Forking is better for transmission. As far as I can see, Type=Simple would be fine, since I can't imagine any service wanting to know when transmission is ready. But I would be fine either way, that decision is up to you.
Comment by Tom Gundersen (tomegun) - Thursday, 12 July 2012, 18:08 GMT
I think we should go with correctness, so Type=Forking. I have packaged this locally, where transmission "just works" without the need for setting any configuration at all (such as selecting your user etc).

ioni: if you want I could make a suggestion for a package change.

It would mean:
1) add a "transmission" user, with home dir /var/lib/transmission
2) add systemd service file
3) add tmpfile fragment to be able to store the pidfile as non-root
4) simplify the rc script accordingly (optional)
Comment by Marius (65kid) - Wednesday, 15 August 2012, 15:19 GMT
any update on this?
Comment by Tom Gundersen (tomegun) - Wednesday, 15 August 2012, 15:28 GMT
At the top of my TODO. Maybe today if I manage to get time.
Comment by Tom Gundersen (tomegun) - Thursday, 16 August 2012, 08:46 GMT
Pushed to testing, please let me know if it works on systemd/initscripts.
Comment by Marius (65kid) - Thursday, 16 August 2012, 11:51 GMT
1. shouldn't the package also create /var/lib/transmission/? Without this, transmission will fail to create its settings and you can't use the web interface until the settings have been created and you modified the ip whitelist.
2. not sure if I found a bug in systemd here: I can't override transmission.service. even after a "systemctl daemon-reload" it still uses the service file from /usr/lib. If I however delete the symlink /usr/lib/systemd/system/transmissionD.service OR override transmissionD.service as well, it works. Can you confirm this?
3. I noticed that I can't simply edit User= because then transmission fails to create the pid file. What's the best way to deal with this? Change the pid location to /run/user/... ?
Comment by Marius (65kid) - Sunday, 19 August 2012, 08:52 GMT
@Tom: in case you haven't noticed, upstream seems to want to add this after all (see ticket). Nevertheless I would really like to know if anyone can confirm my second point from my post before, I find this really strange.
Comment by Tom Gundersen (tomegun) - Monday, 20 August 2012, 13:00 GMT
Sorry for the delay:
1) good point, i (obviously) already had this, so didn't notice that it was not created. I'll change this and push a new package.
2) this is something we should look into (irrespective of transmission)
3) good question. i think /run/user is not correct, as that is only created when you log in, whereas this is a system service. I think the safest thing to do is to change the owner of /run/transmission (in /usr/lib/tmpfiles.d/transmission.conf).
Comment by Marius (65kid) - Monday, 20 August 2012, 13:09 GMT
overriding the tmpfile by creating it in /etc/tmpfiles.d/ should also work, right? IMHO it would make sense to add a comment to the service file that if you want to override User=, you also have to override the tmpfile accordingly.
Comment by Tom Gundersen (tomegun) - Monday, 20 August 2012, 13:15 GMT
Right, it should be overridden in /etc not changed in /usr (that's what I meant, but my brain is not fully working today).

I already rebuilt and pushed the package with a comment (before reading your latest comment here), not exactly what you suggested, but hopefully will point people in the right direction.
Comment by Tom Gundersen (tomegun) - Monday, 20 August 2012, 13:16 GMT
BTW, if transmission was socket activated, all the pidfile stuff could be ignored. Maybe something for the future...
Comment by Marius (65kid) - Monday, 20 August 2012, 13:25 GMT
what do you mean by socket activation? I don't see how this would make sense in this case. If I have torrents running and reboot my machine, I want the torrents to continue, even if I don't use the web interface. It should _always_ be running. Or am I missing something?
Comment by Tom Gundersen (tomegun) - Monday, 20 August 2012, 13:30 GMT
The reason we need the pidfile now is in case something else wants to order itself "After=" transmission.service. I suppose this is unlikely to be relevant, but perhaps the various clients need the daemon to be running before they start? (I only use the webfrontend myself).

If transmission had been socket activated, then a socket would be opened by systemd during very early boot so to userspace it appears as if transmission is "always running", so no need to wait for it at all. You'd still be able to always start transmission on boot as now, the only difference would be that we no longer need any ordering dependencies.

I don't really know all the usecases of transmission, so it might be that we could just drop the pidfile stuff straight away as no one cares when transmission is "up and ready".
Comment by Marius (65kid) - Monday, 20 August 2012, 13:41 GMT
ah ok, that makes sense, thanks for the explanation.
Let's see what upstream has to say. But I guess the talks with them could take a while thanks to their awesome reviewing system. ;)
Comment by Tom Gundersen (tomegun) - Monday, 20 August 2012, 13:47 GMT
yes. i just posted a comment to their tracker. if other have done the same but the comments have not shown up yet it might be a big mess :)
Comment by Marius (65kid) - Monday, 20 August 2012, 13:55 GMT
I'm seriously confused now about the overriding issue I mentioned earlier, I suddenly can't reproduce it anymore. mh, I probably messed up somewhere else, who knows...

anyway, overriding both the service file and the tmpfile seems to work fine.
You can close this ticket if you want, thanks. :)