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 ;-)

I commented on the upstream ticket, and suggested my own service file there :)

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
EnvironmentFile=/etc/conf.d/transmissiond
User=$TRANS_USER

...but this doesn't work because systemd doesn't allow environment variables in User=. :(

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...

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.

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.

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)

any update on this?

At the top of my TODO. Maybe today if I manage to get time.

Pushed to testing, please let me know if it works on systemd/initscripts.

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/... ?

@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.

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).

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.

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.

BTW, if transmission was socket activated, all the pidfile stuff could be ignored. Maybe something for the future...

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?

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".

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. ;)

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 :)

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. :)