Transmission daemon crash

[krx]

Hello,

Sometimes transmission daemon crashes after some time. When restarted, it stars verifying all torrents what were in downloading state when crash occured.

1. Transmission 1.50 instaled as opt-ware from NSLUG repository, on USB stick.
   
2. on Asus WL-500G Premium V2
   
3. F/W DD-WRT v24-sp2 (01/01/09) mega (SVN revision 11296M NEWD Eko)
   

Bellow I attach related syslog entries.

[2000adm]

I have the same problem. Transmission-daemon freezes after ~20-24 hours of working. Transmission 1.51 (7970)

s1:~ # uname -a Linux 2.6.27.19-3.2-default #1 SMP 2009-02-25 15:40:44 +0100 x86_64 x86_64 x86_64 GNU/Linux

Transmission have been compiled from ​http://mirrors.m0k.org/transmission/files/transmission-1.51.tar.bz2

[charles]

@krx: Thanks for reporting this bug to try to help improve Transmission. Unfortunately I've no way to convert this crash report into useful information. Is there any other type of backtrace that you can generate in optware?

[krx]

Replying to charles:

@krx: Thanks for reporting this bug to try to help improve Transmission. Unfortunately I've no way to convert this crash report into useful information. Is there any other type of backtrace that you can generate in optware?

I hoped so, while posting :-) :-|.

I beg my pardon, but I am totally green in debugging area for Linux ;-) Maybe you have some hints/FAQ for process. I would gladly try to help.

The other thing is that even the router itself sometime crashes and reboots, but I am unable to correlate that to Transmission crashes. Some HW/firmware problem perhaps? I will try to upgrade to the latest firmware, perhaps run some RAM test, if that is possible/available.

[KyleK]

That optware release, is it the official 1.51 stable, or a later development build from the trunk?

(My gut tells me that the ratio-control implemented in the trunk might be responsible for these crashes)

[krx]

Replying to KyleK:

That optware release, is it the official 1.51 stable, or a later development build from the trunk?

(My gut tells me that the ratio-control implemented in the trunk might be responsible for these crashes)

1.51 stable. I have not seen beta/RC level optware releases, because I think on that source the process owners include only stable versions.

[Ger Teunis]

On the NMT (Networked Media Tank) hardware (MIPS32 cpu) a lot of users, including myself see this as well. The complete box is hanging after some aggressive download. It's not a cpu overheat problem. If I can help pin pointing the bug please tell me what to do :)

[Ger Teunis]

Ps> I am using version 1.51 (release revision)

[krx]

Replying to Ger Teunis:

On the NMT (Networked Media Tank) hardware (MIPS32 cpu) a lot of users, including myself see this as well. The complete box is hanging after some aggressive download. It's not a cpu overheat problem. If I can help pin pointing the bug please tell me what to do :)

Well, at least I am not alone =)

[charles]

Well, this is a fun ticket. So far we've seen that (1) it crashes, or (2) it freezes, or (3) it makes the entire box hang. The only details are some numbers from a binary crash report in a format I can't read. :)

I don't even know if these are all the same issue. I'd be happy to try to fix things, but so far this ticket is just noise because there's nothing concrete for me to look into.

[krx]

Replying to charles:

Well, this is a fun ticket. So far we've seen that (1) it crashes, or (2) it freezes, or (3) it makes the entire box hang. The only details are some numbers from a binary crash report in a format I can't read. :)

I don't even know if these are all the same issue. I'd be happy to try to fix things, but so far this ticket is just noise because there's nothing concrete for me to look into.

I completely understand your view =) May you please give some details, on how to debug this issue? I would gladly try to help. My knowledge is limited here, and I would not like to dig for a needle in the haystack.

One more issue - transmission daemon after some time start to not respond to command line commands. Command line commands, like transmission-remote -l after running just run without any output whatsoever. Only Ctrl+Break quits them. There is no any timeout even, which should be expected.

Firmware of dd-wrt is the latest, it did not help. I will look for some CPU/RAM test, if there are any.

[krx]

RAM check did not reveal any errors, has run for x500 cycles.

[brazzy]

I'm trying to run Transmisson 1.51 on a WD My World NAS server.
The binary is from:
​http://ipkg.nslu2-linux.org/feeds/optware/cs05q3armel/cross/unstable[[BR]]

Starting the traffic-daemon appears to function fine, but when I connect via a client (firefox, IE, etc) it only partially downloads a few files (not torrent files, but web page for the GUI, I can watch them in fiddler) and then crashes.

Before the crash, the transmission web server starts return server error 502 to my client browser for javascript and other files loaded by the index.html starter page.

Log below:

[root@MyBookWorld bin]# ./transmission-daemon -f -vv
[02:49:32.691] Couldn't create socket: Address family not supported by protocol
[02:49:32.693] RPC Server: Adding address to whitelist: 127.0.0.1
[02:49:32.693] RPC Server: Adding address to whitelist: 192.168.1.*
[02:49:32.694] RPC Server: Serving RPC and Web requests on port 9091
[02:49:32.695] RPC Server: Whitelist enabled
[02:49:32.696] Transmission 1.51 (7970) started
[02:49:33.689] %s succeeded (%d): initnatpmp succeeded (0)
[02:49:33.690] %s succeeded (%d): sendpublicaddressrequest succeeded (2)
[02:49:41.727] Found Internet Gateway Device "%s": Found Internet Gateway Device "http://192.168.1.98:60656/"
[02:49:41.728] Local Address is "%s": Local Address is "192.168.1.98"
[02:49:41.735] : Port forwarding through "http://192.168.1.98:60656/", service "".  (local address: 192.168.1.98:51413)
[02:49:41.735] Starting: Starting
[02:49:41.735] Opened port %d on %s to listen for incoming peer connections: Opened port 51413 on 0.0.0.0 to listen for incoming peer connections
[02:49:41.736] Starting: Starting
[02:49:41.738] Searching for web interface file "/root/.local/share/transmission/web/javascript/transmission.js"

Crash

The config file seems to be ok. I do wonder why it looks for the transmission.js in ~/.local/.... instead of the compiled /opt/share/.... structure. I wonder if the application is changing the current working directory and breaking the search for web page requested files? I can't believe there isn't a report on missing files in the code in an error message.

Anything else I could try?

Any suggestions for an alternate torrent downloader? Seeing obvious printf problems in the log tells me this code is not very polished.

Brazzy

[KyleK]

You could try setting some environment variables:

export TR_DEBUG=2
export TR_DEBUG_FD=1

This will create a motherload of output once you started Transmission. It might help poinpointing the source of the crash though.

[KyleK]

Oh, and running it through gdb would be even better. There should be a gdb package in the optware repository.

[KyleK]

Replying to brazzy:

Starting the traffic-daemon appears to function fine, but when I connect via a client (firefox, IE, etc) it only partially downloads a few files (not torrent files, but web page for the GUI, I can watch them in fiddler) and then crashes.

Before the crash, the transmission web server starts return server error 502 to my client browser for javascript and other files loaded by the index.html starter page.

Log below:

[root@MyBookWorld bin]# ./transmission-daemon -f -vv
[02:49:32.691] Couldn't create socket: Address family not supported by protocol
[02:49:32.693] RPC Server: Adding address to whitelist: 127.0.0.1
[02:49:32.693] RPC Server: Adding address to whitelist: 192.168.1.*
[02:49:32.694] RPC Server: Serving RPC and Web requests on port 9091
[02:49:32.695] RPC Server: Whitelist enabled
[02:49:32.696] Transmission 1.51 (7970) started
[02:49:33.689] %s succeeded (%d): initnatpmp succeeded (0)
[02:49:33.690] %s succeeded (%d): sendpublicaddressrequest succeeded (2)
[02:49:41.727] Found Internet Gateway Device "%s": Found Internet Gateway Device "http://192.168.1.98:60656/"
[02:49:41.728] Local Address is "%s": Local Address is "192.168.1.98"
[02:49:41.735] : Port forwarding through "http://192.168.1.98:60656/", service "".  (local address: 192.168.1.98:51413)
[02:49:41.735] Starting: Starting
[02:49:41.735] Opened port %d on %s to listen for incoming peer connections: Opened port 51413 on 0.0.0.0 to listen for incoming peer connections
[02:49:41.736] Starting: Starting
[02:49:41.738] Searching for web interface file "/root/.local/share/transmission/web/javascript/transmission.js"

Crash

The config file seems to be ok. I do wonder why it looks for the transmission.js in ~/.local/.... instead of the compiled /opt/share/.... structure. I wonder if the application is changing the current working directory and breaking the search for web page requested files? I can't believe there isn't a report on missing files in the code in an error message.

Anything else I could try?

Any suggestions for an alternate torrent downloader? Seeing obvious printf problems in the log tells me this code is not very polished.

Brazzy

This must be an issue with your machine and/or your build of Transmission. I don't see the unresolved placeholders on my NAS.

I furthermore very much doubt that anyone will recommend you a different torrent client, especially in this place.

[charles]

Is there any more information available about this ticket?

[brazzy]

Ok

I installed the latest transmission 1.51 from the correct repository for the Western Digital My Book World Edition.

I set the TR_DEBUG=2 and TR_DEBUG_FD=1

When I launch I get some extra information and then I get a repeating loop of:

[22:01:57.183] 0 peers to go round-robin for upload (bandwidth.c:216)
[22:01:57.183] 0 peers to go round-robin for download (bandwidth.c:216)

Until I attempt to connect to the web interface, in which case it crashs without any other error message or information. I'm lauching transmission as 'transmission-daemon -f' via the console.

Anything else I could try?

-Brazzy

[brazzy]

More information:

I set export TRANSMISSION_WEB_HOME=/opt/share/transmission/web and that removed the warning about not finding the .js files. But the crash is still same.

I tried ever variation of the EVENT_NOxxx environmental variables with no change in the crash behavior.

I made sure the download directory exists and is writable by world.

-Brazzy

[KyleK]

Try setting the environment variable TR_CURL_VERBOSE=1. The additional output might help.

[charles]

Brazzy: Please run transmission-daemon in the foreground inside of a gdb session and attach the backtrace.

KyleK: do you have any tips on how to track down problems on these systems? There are a handful of these crash reports on embedded systems, and none of them seem to make any sense.

[KyleK]

charles: I don't use the NSLUG/NSLU2 optware on my NAS, unfortunately, so I'm afraid I can't help much out here. I know that NSLU2 has a gdb package, whether it runs on any of these devices I don't know. It doesn't work with Transmission on my NAS :( There's some threading issue I haven't been able to figure out yet.

There really aren't much options on these minimal Linux distributions. Spiking the code with debug output is about the only way that might help.

[charles]

brazzy: there was a typo in the EVENT_NOxxx wiki page that omitted one of things to try. This turned out to be The One that solved the problem for another NAS user, so it might be worth trying EVENT_NOEPOLL on your machine...

[charles]

It's been a month since anyone added any information about this crash, so I'm closing the ticket as incomplete. Please reopen this ticket when more information is available.