Process's getting 'Killed' - no log, plenty free ram

haydent · 01-25-2011, 08:37 PM

Hi, all this is my first post but im resonable linux skilled.

Im running a VPS account with Debian Linux Lenny, Virtualmin/Webmin.

This has only recently started but i dont know at what point, as havent done much on it recently but applied some updates.

Theres always at least 50% free ram when it happens (of 512mb) and basically no CPU activity.

Ive even tried killing off all process's apart from what i believed to be needed to test, (init, sshd, loggers)

I can find mention of the action anywhere in any logs, even though i have klogd and syslog running

It seems to happen at varying intervals fairly regularly with certain processes.

Ive had it happen with a big 'rm -r'

but more regularly with make's , make install's, apt-get (while its awaiting your reply to proceed), and rtorrent.

im sure there's others though but this is what ive been using.

all i get is "Killed" and back to prompt,

if i type "echo $?" i get '137'

there has been some node performance issues at night during backups with the host but they say they havn't implemented any limits and are upgrading hardware to resolve.

thankyou,
Hayden.
Australia.

xeleema · 01-25-2011, 09:31 PM

Greetingz!

Well, the OOM (Out of Memory) Killer may be enabled in the kernel. Check the following;
cat /proc/sys/vm/oom-kill
0 = Off
1 = On

To turn it off, do this;
echo 0 > /proc/sys/vm/oom-kill
However, if the system panics, you might want it to auto-reboot.
echo number_of_seconds > /proc/sys/kernel/panic

Note that if the OOM Killer is the culprit, you can edit /etc/sysctl.conf to make the settings stick.
(If you don't have an /etc/sysctl.conf, find and update your rc.local script with the commands from above)

Code:

# reboot 9 secs after panic
kernel.panic = 9
# turn off oom-killer
vm.oom-kill = 0

Hope this helps!

P.S: If you're getting an Exit Code of 137, there's a chance that something did a "kill -9" against that process. If your Hosting provider is going to be replacing/upgrading hardware, I bet it has to do with the RAM.

haydent · 01-25-2011, 09:58 PM

well i dont have that file oom-kill where you suggested or anywhere according to 'find / -name oom-kill'

...

xeleema · 02-02-2011, 10:02 AM

Wow, my apologies for missing your update to this thread.
By chance have they completed their upgrades/repairs? Has the problem gone away?

haydent · 02-02-2011, 03:44 PM

still happening but i don't believe the update has happened yet.

i do have a ticket open with support and am waiting for that.

haydent · 02-08-2011, 05:47 PM

ok i found out what it was... Jumba (my host) have a ban on anything related or even mentioning the word 'torrent' killing it off, that as ive found from my personal experience the hard way will include apt-get install/removes , rm, wget, make, configure, and pretty much anything as well obviously the process's themselves once running like rtorrent

oh well...

thanks for the help.

xeleema · 02-08-2011, 09:27 PM

You've *got* to be kidding me?! Talk about interference! If they're so concerned with (il)legitmate torrent use, why not just throttle the bandwidth for those protocols?

Did they mention how they're doing this? I'd like to find out how they've implemented something like this...because from what you've said, there might be some real skill involved in implementing this.

Does it affect you when you do an "rm -rf /path/to/dir" when the actual path you're rm'ing doesn't contain the word "torrent"?

(Also, was this mentioned anywhere in their Terms-of-Service when you signed up? I'd be super pissed to find out about something like that after-the-fact)