Need re-run for Transmission after killed by SnakeOs

[GoogleCodeExporter]

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.

Original issue reported on code.google.com by Hams...@gmail.com on 2 Apr 2010 at 7:47

[GoogleCodeExporter]

Original comment by dgazi...@gmail.com on 5 Apr 2010 at 5:36

[GoogleCodeExporter]

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. 

Original comment by Shm...@gmail.com on 26 Apr 2010 at 11:24

Attachments:

• [snakeOS 1-1-0 - Transmition 1-92.txt](https://storage.googleapis.com/google-code-attachments/snake-os/issue-4/comment-2/snakeOS 1-1-0 - Transmition 1-92.txt)

[GoogleCodeExporter]

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

Original comment by willia...@gmail.com on 19 May 2010 at 3:10

[GoogleCodeExporter]

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. 

Original comment by Shm...@gmail.com on 19 May 2010 at 3:30

[GoogleCodeExporter]

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.

Original comment by Hams...@gmail.com on 19 May 2010 at 6:04

[GoogleCodeExporter]

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".

Original comment by dar...@gmail.com on 4 Jun 2010 at 7:46

[GoogleCodeExporter]

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. 

Original comment by Shm...@gmail.com on 5 Jun 2010 at 6:40

[GoogleCodeExporter]

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?

Original comment by nileshme...@gmail.com on 8 Jul 2010 at 10:50

Attachments:

• [SnakeOS 1.2 Transmission 2.txt](https://storage.googleapis.com/google-code-attachments/snake-os/issue-4/comment-8/SnakeOS 1.2 Transmission 2.txt)

[GoogleCodeExporter]

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

Original comment by patrick....@gmail.com on 9 Jul 2010 at 9:08

[GoogleCodeExporter]

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

Original comment by nileshme...@gmail.com on 20 Jul 2010 at 2:15

[GoogleCodeExporter]

Also try turning off DHT it might help temporarily.

Original comment by nileshme...@gmail.com on 22 Jul 2010 at 9:48

[GoogleCodeExporter]

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

Original comment by francisc...@gmail.com on 4 Sep 2010 at 3:29

[GoogleCodeExporter]

Dear Mr  francisc...@gmail.com,

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

thank you

Original comment by wickum.m...@gmail.com on 14 Sep 2010 at 4:06

[GoogleCodeExporter]

Just type:

echo 100 > /proc/sys/vm/swappiness

in terminal

Original comment by francisc...@gmail.com on 18 Sep 2010 at 7:54

[GoogleCodeExporter]

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?

Original comment by rafaelas...@gmail.com on 14 Oct 2010 at 4:39

[GoogleCodeExporter]

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.

Original comment by luisfmr...@gmail.com on 29 Oct 2010 at 6:35

[GoogleCodeExporter]

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.

Original comment by xla...@gmail.com on 2 Nov 2010 at 9:39

[GoogleCodeExporter]

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
}

Original comment by cary.win...@gmail.com on 4 Nov 2010 at 8:32

[GoogleCodeExporter]

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.

Original comment by xla...@gmail.com on 4 Nov 2010 at 9:00

[GoogleCodeExporter]

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! 

Original comment by edfcas...@gmail.com on 8 Nov 2010 at 11:28

[GoogleCodeExporter]

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.

Original comment by eulerdgr...@gmail.com on 14 Nov 2010 at 1:27

[GoogleCodeExporter]

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.

Original comment by eulerdgr...@gmail.com on 15 Nov 2010 at 5:12

[GoogleCodeExporter]

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

Original comment by ureng...@gmail.com on 25 Nov 2010 at 7:54

[GoogleCodeExporter]

@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')

Original comment by tuxbox.g...@gmail.com on 25 Nov 2010 at 11:43

[GoogleCodeExporter]

@tuxbox.guru

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

Original comment by smcmp...@gmail.com on 28 Nov 2010 at 6:31

[GoogleCodeExporter]

@tuxbox.guru,

It might be possible to fix this issue but it seems to require debugging the 
nic driver. However, I've noticed newer kernels have support for a different 
Star chip so it might be simpler to try and backport its nic driver. 
Unfortunately I don't have the means for doing that myself.

I could try the usb-ether solution, but I would guess it'll require some extra 
modules. That's no problem, for I managed to compile a few kernel modules 
myself for testing and they worked just fine, like the nfs-kernel module.

Nevertheless, there seem to be other serious issues with the kernel, like the 
memory leaks I mentioned before. Upgrading to a newer kernel might fix them, 
but this will require migrating the various patches on the present kernel. I 
tried it, but after the first or second migration it becomes a real mess. Well, 
I guess I not qualified for that kind of work anyway, but I thought it'd be 
kind of fun to try.

Regards,
Euler

Original comment by eulerdgr...@gmail.com on 29 Nov 2010 at 1:10

[GoogleCodeExporter]

It would be great if someone will buy cheap USB-Ethernet adapter ($5-$10 on 
DealExtreme), test it and then publish here kernel module for it.

Another option is using the following driver (can somebody try this ?):
https://github.com/dmarion/linux-2.6-cns21xx/tree/cns21xx-2.6.37-work/drivers/ne
t/cns21xx

Original comment by stanisl...@gmail.com on 6 Mar 2011 at 3:01

[GoogleCodeExporter]

I've got the same problems. transmissionservice stops very often and needs to 
be restarted. I'm using a 1GB usb memory-stick for swapdrive.
any ideas?
Kind regards,
Leon

Original comment by leonbakk...@gmail.com on 3 Apr 2011 at 5:23

[GoogleCodeExporter]

So, in the end I bought cheap USB-Ethernet adapter, built driver and startup 
script, and published it in the following SnakeOS forum thread:
http://code.google.com/p/snake-os/issues/detail?id=11#c64

Original comment by stanisl...@gmail.com on 5 May 2011 at 2:09