#4 Need re-run for Transmission after killed by SnakeOs

[Anonymous]

Originally created by: Hams...@gmail.com
Originally owned by: dgazi...@gmail.com

What steps will reproduce the problem?
1.Torrent files which are larger than 12GB
2. Verifying procodure.
3. SnakeOs is just waiting me to click start transmission button.

What is the expected output? What do you see instead?
Out of memory, Transmission was killed by SnakeOs.

What version of the product are you using? On what operating system?
Snakeos 1.0.0 w/Transmission 1.9.2

Please provide any additional information below.

[Anonymous]

Originally posted by: dgazi...@gmail.com

(No comment was entered for this change.)

Owner: dgazineu

[Anonymous]

Originally posted by: Shm...@gmail.com

I have a similar problem, my transmission crashes soon after adding torrents of any
size. OS1.1.0/transmission 1.92
Not sure if its out of memory, log file attached.

[Anonymous]

Originally posted by: willia...@gmail.com

Try to enable 'swapfile' service. It's seens you're running out of memory ;)

[Anonymous]

Originally posted by: Shm...@gmail.com

Have the swap file running already and its that filling up thats causing the crash.
Ive since dropped the number of connections transmission cant use to 120 and its
working quite well. It does limit the number of torrents I can download at once tho.

[Anonymous]

Originally posted by: Hams...@gmail.com

It doesn't matter, you are running snakeos with/whitout swap. I think there is a
memory leakage problem about it, because after out of memory problem(it's always
causing after 2 days) restart of the transmission doesn't solve the problem. 3 or 4
minutes are enough to see same problem again. You have to restart whole snakeos to
reach again 2 days period.

[Anonymous]

Originally posted by: dar...@gmail.com

I have this issue with snakeOS 1.0.0 and 1.1.0, same behavior.
Bought it on ebay with snake 1.0.0 already loaded, worked fine for about a week, then
upgraded to 1.1.0, transmission started to crash so I downgraded to 1.0.0, but the
problem keeps ocurring.
After the first upgrade, the nas stopped responding so I resetted it, and it bricked
it, so Y tried to repair it through the serial port but couldn't, so I desoldered the
flash and with a parallel programmer and a software found on a russian page I
repaired it copying the 1.1.0 "from-original".

[Anonymous]

Originally posted by: Shm...@gmail.com

Ive had some good success by reducing the number of connections. Haven't had a crash
in a long time but it does start to get very slow to respond after about 5 days so i
restart. But i haven't lost a torrent or had a crash since then.

[Anonymous]

Originally posted by: nileshme...@gmail.com

Even with free swap space Transmission gets killed (SnakeOS 1.2 Transmission 2). Any idea why? If I use a swap partition would it help?

[Anonymous]

Originally posted by: patrick....@gmail.com

This the problem with oom-killer,
maybe you should use this : http://www.mnis.fr/en/support/doc/oomkiller/

[Anonymous]

Originally posted by: nileshme...@gmail.com

If you are using the swap files or swap partition try changing the swappiness to 80. Does anyone notice any improvement? Less crashing?

[Anonymous]

Originally posted by: nileshme...@gmail.com

Also try turning off DHT it might help temporarily.

[Anonymous]

Originally posted by: francisc...@gmail.com

I got good results by restarting NAS and setting swappiness to 100.
It didn't crash yet in 2 days.

[Anonymous]

Originally posted by: wickum.m...@gmail.com

Dear Mr  francisc...@gmail.com,

kindly give me the firmware which you have set swappiness to 100?

thank you

[Anonymous]

Originally posted by: francisc...@gmail.com

Just type:

echo 100 > /proc/sys/vm/swappiness

in terminal

[Anonymous]

Originally posted by: rafaelas...@gmail.com

Hi francisc...@gmail.com,

I'm using the Snake v1.2 on Windows 7 today.
How could I run this command on my NS-K330?

[Anonymous]

Originally posted by: luisfmr...@gmail.com

Newbie here - sorry for the inconvenience

This alteration to swappiness, how can it be made permanent?

I mean in order for swappiness to be maintained with value 100 instead of default 60 uppon NAS restart?

because it realy makes a difference with my NAS and torrents.

thank you so much.

[Anonymous]

Originally posted by: xla...@gmail.com

This problem related to oom-killer. You can update transmission startup script and change scoring for oom-killer.

Just add this lines in /etc/init.d/transmission after nohup command in start() section and save changes:

        PID=$(pidof transmission-daemon | cut -d ' ' -f 1)
        echo -17 > /proc/$PID/oom_adj

This will write -17 code to /proc/[PID]/oom_adj and will instruct oom-killer to never kill transmission.

[Anonymous]

Originally posted by: cary.win...@gmail.com

Thanks for your input xlamik, I have tried to implement it a few times, and it's not working for me. oomkiller is still killing the transmission process. Here is the start() section of the transmission file from /etc/init.d on my NAS device. Have I implemented your fix correctly? If not, could you please point out where it should go?

Thanks!

start() {
        PID=$(pidof transmission-daemon | cut -d ' ' -f 1)
        if [ ${PID:-empty} = "empty" ] ; then
            USE_TRANSMISSION=$(grep "use_transmission=" /etc/default/config | cu
            if [ $USE_TRANSMISSION -eq 1 ] ; then
                        rm -f /var/transmission
                        ln -s "${TRANS_DIR}" /var/transmission
                    if [ -f /var/transmission/.config/transmission-daemon/settin
                                mkdir -p /var/transmission/torrentwatch
                            echo "Starting $KIND service..."
                            set_password
                                cp -a /etc/default/settings.json /var/transmissi
                        cd $TRANS_BIN
                        nohup nice -n 15 ./transmission-daemon -g /var/transmiss
                        PID=$(pidof transmission-daemon | cut -d ' ' -f 1)
                        echo -17 > /proc/$PID/oom_adj
                    else
                        if [ ${TRANS_DIR:-empty} = "empty" ] ; then
                            echo "Transmission directory was not set. Please set
                        else
                            TRANS_MOUNTED=`echo ${TRANS_DIR} | cut -d '/' -f 3`
                            for MOUNT in $(grep "^/dev/sd" /proc/mounts | cut -d
                                if [ $MOUNT = $TRANS_MOUNTED ] ; then
                                    FOUND=1
                                    mkdir -p /var/transmission/.config/transmiss
                                    mkdir -p /var/transmission/torrentwatch
                                    cp -a /etc/default/settings.json /var/transm
                                    set_password
                                    echo "Starting $KIND service..."
                                    cd $TRANS_BIN
                                    nohup nice -n 15 ./transmission-daemon -g /v
                                    sleep 2
                                fi
                                    done
                            if [ ${FOUND:-0} -eq 0 ] ; then
                                echo "Transmission dir not mounted. Mount it or
                            fi
                        fi
                    fi
                fi
        fi
}

[Anonymous]

Originally posted by: xla...@gmail.com

Hi Cary,

I monitored transmission for 1 week and found that oom-killer is killing other daemons instead of transmission.

Moreover I am using completely modified startup script and forgot that standard one has 2 section.

So  add the same command after nohup in this section.
else
                            TRANS_MOUNTED=`echo ${TRANS_DIR} | cut -d '/' -f 3`
                            for MOUNT in $(grep "^/dev/sd" /proc/mounts | cut -d
                                if [ $MOUNT = $TRANS_MOUNTED ] ; then
                                    FOUND=1
                                    mkdir -p /var/transmission/.config/transmiss
                                    mkdir -p /var/transmission/torrentwatch
                                    cp -a /etc/default/settings.json /var/transm
                                    set_password
                                    echo "Starting $KIND service..."
                                    cd $TRANS_BIN
                                    nohup nice -n 15 ./transmission-daemon -g /v
>> HERE
                                    sleep 2

Alternatively, for test purposes, you can manually execute commands after transmission starts.

[Anonymous]

Originally posted by: edfcas...@gmail.com

well, what I´m doing to avoid crash of transmission is keeping few concurrent torrents. I use to let only 3 or 4 torrents. Strange is that no matter if the torrents are running or paused!

[Anonymous]

Originally posted by: eulerdgr...@gmail.com

I've been having the same problem, and carried out a few experiments. After a while, depending on how much activity there has been, I noticed the cached memory is gradually reduced until there isn't enough, so transmission gets killed by oom-killer. Restarting transmission doesn't seem to help, since the cached memory doesn't go back to it's former levels. I'm beginning to suspect there is a serious memory leak somewhere in the kernel. Version 2.6.16 seems particularly buggy and at this moment an updated kernel could be the solution.

[Anonymous]

Originally posted by: eulerdgr...@gmail.com

I am beginning to suspect there are serious issues with this kernel. Memory allocation seems to be leaky and the tcp stack is showing a strange choking condition that causes communication to cease momentarily or die unexpectedly. Netstat will reveal the transmission queue is stuck with some packets awaiting to go.

This happens more often when my box is connected to a Linksys WRT54GL router than with a direct connection with another computer, but it does occur in all situations and is fairly reproducible, although I couldn't determine an exact situation that would trigger it. Seems to occur with all tcp/udp communications, although the nic shows no error whatsoever

Is there a not so difficult way of replacing the present kernel? I believe it will fix, at least partly, the above problems with transmission.

[Anonymous]

Originally posted by: ureng...@gmail.com

Comment 14 by francisc...@gmail.com, Sep 18, 2010
Just type:

echo 100 > /proc/sys/vm/swappiness

in terminal

it is correct, and else

echo 50 > /proc/sys/vm/vfs_cache_pressure

in terminal

[Anonymous]

Originally posted by: tuxbox.g...@gmail.com

@eulerdgraca,

I agree.. the starNIC driver is really suspect. I disabled it and started using a USB-Ethernet and now I can play video directly from the NAS device and the DLNA software works without any problems.. (Previously would play for a few minutes and then abort with 'Too many errors')

[Anonymous]

Originally posted by: smcmp...@gmail.com

@tuxbox.guru

Could you list the steps involved in using a USB-Ethernet adapter? I assume it's not plug and play?