I've tried running both transmission and deluge on my raspberry pi. Both times fresh install.

I can get it up and running fine, but then after about 1-2 minutes the web server stops responding and I can't access it unless i restart. I know it's not the whole pi crashing as I can still access pyLoad which is also running along with OpenVPN.

I first thought it was the problem of the applications. But now both are having the same problems I feel it is definitely not the application and rather the OS/hardware.

Has anyone had similar and found a fix?

UPDATE I ran netstat -ano|grep 9091 and got:

Proto Recv-Q  Send-Q  Local Address        Foreign Address                 State

tcp      0      0*            LISTEN off (0.00/0/0)
tcp      0      0   ESTABLISHED keepalive (6879.20/0/0)
tcp      0      0   ESTABLISHED keepalive (6879.20/0/0)
tcp      0      0   ESTABLISHED keepalive (6879.20/0/0)
tcp     1123    0   ESTABLISHED keepalive (6940.61/0/0)
tcp     707     0   ESTABLISHED keepalive (6879.17/0/0)
tcp      0      0   ESTABLISHED keepalive (6879.17/0/0)
tcp      0      0   ESTABLISHED keepalive (7104.42/0/0)
tcp      0      0   ESTABLISHED keepalive (6879.14/0/0)
tcp      0      0   ESTABLISHED keepalive (7124.90/0/0)
tcp      0      0   ESTABLISHED keepalive (6879.14/0/0)
tcp      0      0   ESTABLISHED keepalive (6879.14/0/0)
tcp      0      0   ESTABLISHED keepalive (6879.12/0/0)
tcp      0      0   ESTABLISHED keepalive (6879.12/0/0)

UPDATE 2 Right I think I've found the issue. It is to do with the openvpn. Once connected for some reason the port is open for a few minutes to LAN traffic before being closed. This however doesn't seem to be the case for pyload which is also running (port 8000)

I think what I need to do is ensure that all outbound traffic (to the WAN) is going over vpn (i.e. tun) but all LAN traffic is not routed through the vpn. To be honest I'm not sure how to do this. I've done a bit of research and came across these iptable rules (Linky), however I'm not sure if they're working and I still can't access port 9091.

iptables --append OUTPUT --destination --protocol tcp --dport 1723 --jump ACCEPT
iptables --append OUTPUT --destination --protocol gre --jump ACCEPT

My understanding of this is this forces all of the WAN traffic over my tun connection and allows port 1723 for the vpn tracker. However, I might be wrong in this. Can anyone help?

  • 1
    Does the server have a log that might provide some clues? Is the process still running and just unresponsive, or has it disappeared? If you understand a little about packets and protocols, you might try looking at what's happening with a tool like wireshark. You don't need to use the pi for that, just another system on the same LAN; if the LAN is busy you'll have to do some filtering...so a bit of learning curve but getting comfortable with a packet sniffer can come in useful for a lot of things.
    – goldilocks
    Dec 3, 2014 at 22:24
  • Thanks! It might do, but I'm not sure how to access it. I've downloaded wireshark, and there is a lot of stuff flying past! Any clues as to what I'm looking for?
    – Tom
    Dec 3, 2014 at 23:28
  • Here's a possible entry to the wireshark docs. I'm not a torrent user so I don't know the port number used by the server, but if you use tcp.port eq ___ or udp.port eq ___ as the filter, where ___ is the port number, you'll limit the output to stuff coming to or from the server. If you do that, start it, and watch until it fails, there might be a clue.
    – goldilocks
    Dec 4, 2014 at 0:03
  • It came back blank. I also tried using a filter on the source and destination of the servers ip and it came back with only MDNS entries and no TCP (not sure what that means exactly)
    – Tom
    Dec 4, 2014 at 0:10
  • If it's blank while you are able to witness the server definitively responding from another point, then you've done something wrong -- the packets are there. I was thinking in regards to the 1-2 minutes you mention before it stops. You should be able to witness that happen. E.g., if the application has failed, the OS will respond with an ICMP message (so whoops, that filter should have been something more like icmp or tcp.port eq 9091), unless you've customized an iptables set up otherwise...
    – goldilocks
    Dec 4, 2014 at 2:32

1 Answer 1


The USB driver allocates memory from the kernel, and when traffic is very high (e.g. when using torrents/newsgroup downloads) this memory can be exhausted causing crashes/hangs.

in /etc/sysctl.conf where it says "vm.min_free_kbytes = 8192" Try increasing that number to 16384.

If that doesn't work, try adding to /boot/cmdline.txt "smsc95xx.turbo_mode=N"

The latter worked for me and i stopped having trouble in transmission.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.