Unlimited slow fork of transmission-daemon until OOM

[demofly]

I'm using QNAP TS-559 Pro+ with x86 Intel Atom D525 CPU. Inside the shell it is visible 4 cores. The box has 1 GB of RAM and 512 MB of a swap memory.

I've installed Optware ipkg (it is an onboard function of QNAP firmware), then, I've installed the latest transmission. For the first time it was a version 2.31.

I've started it and tried to attach to it some previously downloaded torrents. Then, after 30 minutes QNAP box has OOM. When I connected to the shell, I've found very many processes of transmission-daemon.

In htop it usually looks like many independent transmission-daemon with 2 child threads per every process. The real first daemon has 3 threads usually.

I've found some recommendation like "It should be 3 processes only iside the box" and wrote transmission-killer.sh:

#!/bin/sh
echo $$ > /var/run/transmission-killer.pid
while [ 1 ]
do
    cnt=0
    for pid in `pidof transmission-daemon`
    do
        ((cnt++))
        if [[ $cnt -le 3 || `cat /var/run/transmission.pid` == $pid ]]
        then
            continue
        fi
        kill -TERM $pid
    done
    sleep 1
done

The main startup script I'm using is transmission.sh:

#!/bin/sh

umask 0000
ulimit -n 65535
. /etc/init.d/functions
# See how we were called.
TORRENTFOLDER=/share/MD0_DATA
TRANSMISSION_BIN=/opt/bin/transmission-daemon
TRANSMISSION_REMOTE=/opt/bin/transmission-remote
TRANSMISSION_HOME=/opt/etc/transmission
TRANSMISSION_USER=transmission
TRANSMISSION_PORT=9091
TRANSMISSION_SEEDPORT=8888
TRANSMISSION_OOM_KILLER=/share/MD0_DATA/transmission-killer.sh
REMOTE_USER=torrents
REMOTE_PASS=asdx

case "$1" in
  start)
        test -f $TRANSMISSION_BIN || (echo "$TRANSMISSION_BIN doesn't exists" && exit 0)
        echo "Starting torrent services:"

        /sbin/daemon_mgr transmission-daemon start "EVENT_NOEPOLL=0 $TRANSMISSION_BIN --blocklist --auth --username $REMOTE_USER --password $REMOTE_PASS --config-dir $TRANSMISSION_HOME --download-dir $TORRENTFOLDER"
        echo -n "transmission-daemon..."
        tdpids=`pidof transmission-daemon`
        while [[ "$tdpids" == "" ]]
        do
            tdpids=`pidof transmission-daemon`
        done
        pidof -s transmission-daemon > /var/run/transmission.pid
        echo " done."
        echo -n "transmission-remote..."
        /sbin/daemon_mgr transmission-remote start "$TRANSMISSION_REMOTE -n $REMOTE_USER:$REMOTE_PASS --portmap --port $TRANSMISSION_PORT --pex --encryption-preferred 2>/dev/null 1>/dev/null"
        echo " done."
        echo -n 'transmission-killer...'
        nohup $TRANSMISSION_OOM_KILLER > /dev/null 2>/dev/null &
        echo " done."
        ;;
  stop)
        echo "Shutting down torrent services:"

        /sbin/daemon_mgr transmission-daemon stop $TRANSMISSION_BIN
        echo -n "transmission-daemon..."
        tdpids=`pidof transmission-daemon`
        while [[ "$tdpids" != "" ]]
        do
            for pid in $tdpids
            do
                /bin/kill -TERM $pid 2>/dev/null 1>/dev/null
                # DEBUG
                # echo /bin/kill -TERM $pid
            done
            tdpids=`pidof transmission-daemon`
        done
        rm -f /var/run/transmission.pid
        echo " done."
        echo -n "transmission-remote..."
        trpids=`pidof transmission-remote`
        /sbin/daemon_mgr transmission-remote stop $TRANSMISSION_REMOTE
        for pid in $trpids; do
            /bin/kill -TERM $pid 2>/dev/null 1>/dev/null
        done
        echo " done."
        echo -n 'transmission-killer...'
        kill -TERM `cat /var/run/transmission-killer.pid`
        rm -f /var/run/transmission-killer.pid
        echo " done."
        ;;
  restart)
        echo "Restarting torrent services:"
        $0 stop
        $0 start
        echo "done."
        ;;
  *)
        echo "Usage: transmission.sh {start|stop|restart}"
        exit 1
        ;;
esac

And this handmade construction allows me to be sure that the NAS box will not go to OOM.

It was about the first, major or even a blocker problem.

But, I've noted the second very big problem. It seeds on 10KB/sec avg. In the same network (it is my home network) Windows with uTorrent seeds 1 MB/sec avg.

Here is my settings.json:

{
    "alt-speed-down": 50,
    "alt-speed-enabled": false,
    "alt-speed-time-begin": 540,
    "alt-speed-time-day": 127,
    "alt-speed-time-enabled": false,
    "alt-speed-time-end": 1020,
    "alt-speed-up": 50,
    "bind-address-ipv4": "0.0.0.0",
    "bind-address-ipv6": "::",
    "blocklist-enabled": true,
    "blocklist-url": "http://www.example.com/blocklist",
    "cache-size-mb": 64,
    "dht-enabled": true,
    "download-dir": "/share/MD0_DATA",
    "encryption": 1,
    "idle-seeding-limit": 30,
    "idle-seeding-limit-enabled": false,
    "incomplete-dir": "/root/Downloads",
    "incomplete-dir-enabled": false,
    "lpd-enabled": true,
    "message-level": 2,
    "open-file-limit": 32,
    "peer-congestion-algorithm": "",
    "peer-limit-global": 8192,
    "peer-limit-per-torrent": 60,
    "peer-port": 9091,
    "peer-port-random-high": 65535,
    "peer-port-random-low": 49152,
    "peer-port-random-on-start": false,
    "peer-socket-tos": "default",
    "pex-enabled": true,
    "port-forwarding-enabled": true,
    "preallocation": 1,
    "prefetch-enabled": 1,
    "ratio-limit": 2,
    "ratio-limit-enabled": false,
    "rename-partial-files": true,
    "rpc-authentication-required": true,
    "rpc-bind-address": "0.0.0.0",
    "rpc-enabled": true,
    "rpc-password": "{1d940fa0ec9f2c7e65552e48e1286a9f49742ae7uRcUx8IC",
    "rpc-port": 9091,
    "rpc-url": "/transmission/",
    "rpc-username": "torrents",
    "rpc-whitelist": "127.0.0.1, 192.168.0.*",
    "rpc-whitelist-enabled": true,
    "script-torrent-done-enabled": false,
    "script-torrent-done-filename": "",
    "speed-limit-down": 100,
    "speed-limit-down-enabled": false,
    "speed-limit-up": 100,
    "speed-limit-up-enabled": false,
    "start-added-torrents": true,
    "trash-original-torrent-files": false,
    "umask": 18,
    "upload-slots-per-torrent": 14,
    "utp-enabled": true
}

Some environment info:

HOSTNAME=SCat
TERM=xterm
SHELL=/bin/sh
HISTSIZE=1000
SSH_CLIENT=192.168.0.153 57677 22
SSH_TTY=/dev/pts/0
LC_ALL=en_US.UTF-8
HISTFILESIZE=1000
USER=root
LS_COLORS=no=00:fi=00:di=01;34:ln=01;36:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.gz=01;31:*.bz2=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.jpg=01;35:*.jpeg=01;35:*.png=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.mpg=01;35:*.mpeg=01;35:*.avi=01;35:*.fli=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:
PAGER=/bin/more
MAIL=/var/mail/admin
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/opt/bin:/opt/sbin
INPUTRC=/etc/inputrc
PWD=/root
EDITOR=/bin/vi
LANG=en_US.UTF-8
DMALLOC_OPTIONS=debug=0x34f47d83,inter=100,log=logfile
PS1=[\w] #
SHLVL=1
HOME=/root
LOGNAME=root
LC_CTYPE=en_US.UTF-8
SSH_CONNECTION=192.168.0.153 57677 192.168.0.160 22
_=/usr/bin/env

and some more info:

[~] # uname -a
Linux SCat 2.6.33.2 #1 SMP Fri May 20 00:42:22 CST 2011 x86_64 unknown
[~] # df
Filesystem                Size      Used Available Use% Mounted on
/dev/ramdisk            139.5M    117.1M     22.4M  84% /
tmpfs                    32.0M    120.0k     31.9M   0% /tmp
/dev/sda4               310.0M    156.4M    153.5M  50% /mnt/ext
/dev/md9                509.5M     49.9M    459.5M  10% /mnt/HDA_ROOT
/dev/md0                  8.1T      1.7T      6.4T  21% /share/MD0_DATA
tmpfs                    32.0M         0     32.0M   0% /.eaccelerator.tmp
[~] # cat /etc/mtab
/proc /proc proc rw 0 0
none /dev/pts devpts rw,gid=5,mode=620 0 0
sysfs /sys sysfs rw 0 0
tmpfs /tmp tmpfs rw,size=32M 0 0
none /proc/bus/usb usbfs rw 0 0
/dev/sda4 /mnt/ext ext3 rw 0 0
/dev/md9 /mnt/HDA_ROOT ext3 rw 0 0
/dev/md0 /share/MD0_DATA ext4 rw,usrjquota=aquota.user,jqfmt=vfsv0,user_xattr,data=ordered,delalloc,acl 0 0
nfsd /proc/fs/nfsd nfsd rw 0 0
tmpfs /.eaccelerator.tmp tmpfs rw,size=32M 0 0
[~] # cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath]
md0 : active raid6 sda3[0] sde3[4] sdd3[3] sdc3[2] sdb3[1]
      8786092608 blocks super 1.0 level 6, 64k chunk, algorithm 2 [5/5] [UUUUU]

md5 : active raid1 sde2[2](S) sdd2[3](S) sdc2[4](S) sdb2[1] sda2[0]
      530048 blocks [2/2] [UU]

md13 : active raid1 sda4[0] sde4[4] sdd4[3] sdc4[2] sdb4[1]
      458880 blocks [5/5] [UUUUU]
      bitmap: 0/57 pages [0KB], 4KB chunk

md9 : active raid1 sda1[0] sde1[4] sdd1[3] sdc1[2] sdb1[1]
      530048 blocks [5/5] [UUUUU]
      bitmap: 3/65 pages [12KB], 4KB chunk

unused devices: <none>

I'm using an official v3.4.3 Build 0520T firmware from QNAP.

I'm an unix system administrator, so feel free to ask me complex questions.

[jordan]

In htop it usually looks like many independent transmission-daemon with 2 child threads per every process. The real first daemon has 3 threads usually.

Wouldn't this be a QNAP issue rather than a Transmission one? It sounds like QNAP is starting up new copies of transmission-daemon for some reason.

transmission-daemon should be a single process with a handful of full-time threads (the main process thread, the libtransmission thread, and a libcurl thread) and a couple of part-time optional threads (checksum hashing, for example).

But what you're describing is actually several instances of transmission-daemon running, which is a different situation.

Are they all created by the same parent process?

[demofly]

Thank you very much! The problem was in reference usage of QNAP /sbin/daemon_mgr. The fixed version of the init.d script which closes the issue about unlimited forks:

transmission.sh:

#!/bin/sh

umask 0000
ulimit -n 65535
. /etc/init.d/functions
# See how we were called.
TORRENTFOLDER=/share/MD0_DATA
TRANSMISSION_BIN=/opt/bin/transmission-daemon
TRANSMISSION_REMOTE=/opt/bin/transmission-remote
TRANSMISSION_HOME=/opt/etc/transmission
TRANSMISSION_USER=transmission
TRANSMISSION_PORT=9091
TRANSMISSION_SEEDPORT=8888
REMOTE_USER=torrents
REMOTE_PASS=asdx

case "$1" in
  start)
        test -f $TRANSMISSION_BIN || (echo "$TRANSMISSION_BIN doesn't exists" && exit 0)
        echo "Starting torrent services:"

        $TRANSMISSION_BIN --blocklist --auth --username $REMOTE_USER --password $REMOTE_PASS --config-dir $TRANSMISSION_HOME --download-dir $TORRENTFOLDER
        echo -n "transmission-daemon..."
        tdpids=`pidof transmission-daemon`
        while [[ "$tdpids" == "" ]]
        do
            tdpids=`pidof transmission-daemon`
        done
        pidof -s transmission-daemon > /var/run/transmission.pid
        echo " done."
        echo -n "transmission-remote..."
        $TRANSMISSION_REMOTE -n $REMOTE_USER:$REMOTE_PASS --portmap --port $TRANSMISSION_PORT --pex --encryption-preferred 2>/dev/null 1>/dev/null
        echo " done."
        ;;
  stop)
        echo "Shutting down torrent services:"

        echo -n "transmission-daemon..."
        tdpids=`pidof transmission-daemon`
        while [[ "$tdpids" != "" ]]
        do
            for pid in $tdpids
            do
                /bin/kill -TERM $pid 2>/dev/null 1>/dev/null
                # DEBUG
                # echo /bin/kill -TERM $pid
            done
            tdpids=`pidof transmission-daemon`
        done
        rm -f /var/run/transmission.pid
        echo " done."
        echo -n "transmission-remote..."
        trpids=`pidof transmission-remote`
        for pid in $trpids; do
            /bin/kill -TERM $pid 2>/dev/null 1>/dev/null
        done
        echo " done."
        ;;
  restart)
        echo "Restarting torrent services:"
        $0 stop
        $0 start
        echo "done."
        ;;
  *)
        echo "Usage: transmission.sh {start|stop|restart}"
        exit 1
        ;;
esac

transmission-killer.sh is not needed anymore! So happy with your help!

So, the second issue about very low seeding is the last issue of the ticket.

[jordan]

demofly, the Transmission development team doesn't include any init scripts in our releases, so the init script you're referring to probably came from QNAP. You need to pass the fix on to them, rather than listing it here, because there's nothing the dev team can do with it here upstream.

I'm personally not seeing any seeding issues in 2.32, but regardless, let's keep to the one-topic-per-ticket rule and discuss that issue separately.

Closing this ticket as invalid as the bug is coming from downstream, rather than from the transmissionbt.com releases.

[demofly]

Anyway, this help was so exact with the subject of the ticket! Thank you!