FS#31794 - [transmission-cli] cannot connect to server after boot-up (systemd)

Attached to Project: Arch Linux
Opened by Radu Potop (wooptoo) - Wednesday, 03 October 2012, 20:15 GMT
Last edited by Dave Reisner (falconindy) - Thursday, 03 October 2013, 13:43 GMT
Task Type Bug Report
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 3
Private No

Details

Description:

I am using systemd 193 and transmission-cli 2.71
After booting up, neither transmission-remote or transmission webui can connect to transmission-daemon. The daemon does not listen on any port, even though it is running.


I get these error messages in journald:

Oct 03 20:22:27 blue transmission-daemon[368]: UDP Failed to set receive buffer: requested 4194304, got 262142 (tr-udp.c:77)
Oct 03 20:22:27 blue transmission-daemon[368]: UDP Failed to set send buffer: requested 1048576, got 262142 (tr-udp.c:88)
Oct 03 20:22:34 blue systemd[1]: PID file /run/transmission/transmission.pid not readable (yet?) after start.


After restarting the service it works, but this is a sub-optimal fix.



Another (smaller) issue is that transmission logs too much data by default, polluting journald with info messages about torrent announces. transmission.service should include an EnvironmentFile where logging and other directives can be set. I attached a modified service file.
This task depends upon

Closed by  Dave Reisner (falconindy)
Thursday, 03 October 2013, 13:43 GMT
Reason for closing:  Duplicate
Additional comments about closing:   FS#31478 
Comment by Zane Fox (zanefox) - Thursday, 18 October 2012, 09:40 GMT
same thing happens here too.
Comment by Yochai Gal (yochaigal) - Wednesday, 07 November 2012, 19:47 GMT
I'm having the same issue.
Comment by Tom Gundersen (tomegun) - Sunday, 11 November 2012, 18:51 GMT
Please keep the bug report separate from the feature request. I don't know off-hand the best solution for the bug.

As to the feature request I don't think this is a good idea. We are trying to avoid the use of the Arch-specific /etc/conf.d/, as once the service file is moved upstream this would have to be dropped. Either configure this in transmission's own config file, or (in case that's not possible) override the config file manually.

If the default debug output is really too high, we might want to ask upstream to change that...?
Comment by Radu Potop (wooptoo) - Sunday, 11 November 2012, 19:00 GMT
Regarding the feature request: we might convince upstream to use the --log-error flag by default, since there is no option in the transmission config to control logging level.
Comment by Tom Gundersen (tomegun) - Sunday, 11 November 2012, 20:15 GMT
Or we could set it to be the default in the file we ship I guess. Might be more sane than the current behaviour.

Comment by Radu Potop (wooptoo) - Sunday, 11 November 2012, 20:46 GMT
I found the upstream feature request and they seem to be using Arch systemd integration as a model: https://trac.transmissionbt.com/ticket/4503
So maybe it would make sense to put that flag in our service file. I posted on their Trac too (not displayed yet, needs approval).
Comment by Eugene Diachkin (Ineu) - Saturday, 05 January 2013, 16:20 GMT
Same bug on transmission-cli 2.75-1. Web/RPC interface on port 9091 is not run right after boot but run after manual systemctl restart.
Comment by Stefan J. Betz (encbladexp) - Tuesday, 05 February 2013, 18:19 GMT
Same issue as #31478?
Comment by Eugene Diachkin (Ineu) - Tuesday, 05 February 2013, 20:30 GMT
Yes, fix from 31478 works.
Comment by Anatol Pomozov (anatolik) - Saturday, 01 June 2013, 14:53 GMT
> Another (smaller) issue is that transmission logs too much data by default

Agree! Transmission dumps a lot of unneeded garbage to syslog. I fixed this issue by updating transmission config file and setting 'message-level' option into 1 https://trac.transmissionbt.com/wiki/EditConfigFiles

Steps that I did:
1) Stop transmission daemon. It is important because transmission keeps options in memory and updates config file on shutdown.
2) Update transmission config file. In my case it was ~transmission/.config/transmission-daemon/settings.json Set 'message-level' option to 1
3) Start transmission.


I think this 'quieter' mode should be set by default. Current INFO log level is too verbose.

Loading...