From: Brian Candler <lists@...>
Date: 2012-09-10T04:51:15+09:00
Subject: Re: Long calculation & time limit

toto tartemolle wrote in post #1075217:
>>ulimit -a
> core file size          (blocks, -c) 0
> data seg size           (kbytes, -d) unlimited
> scheduling priority             (-e) 20
> file size               (blocks, -f) unlimited
> pending signals                 (-i) 16382
> max locked memory       (kbytes, -l) unlimited
> max memory size         (kbytes, -m) unlimited
> open files                      (-n) 1024
> pipe size            (512 bytes, -p) 8
> POSIX message queues     (bytes, -q) 819200
> real-time priority              (-r) 99
> stack size              (kbytes, -s) 8192
> cpu time               (seconds, -t) unlimited
> max user processes              (-u) unlimited
> virtual memory          (kbytes, -v) unlimited
> file locks                      (-x) unlimited

Well it was a long shot, but I just wanted to check that cpu time was 
unlimited (which it is).

>>Message at full
>
> litterally: "Killed, returned error 137"

Nothing else? No ruby backtrace, nothing?

Actually that makes sense. As has been pointed out, 137 = 128 (killed) 
+9 (SIGKILL). This means that some other process sent a kill signal, 
e.g. using "kill -9 <pid>", which ruby cannot trap; it dies instantly.

However it is up to you to find out which other process sent the signal. 
Have you or someone on this system implemented some sort of watchdog 
process? This is *not* default behaviour.

Try running a simple infinite loop:

    ruby -e 'loop {}'

Does this also die?

Another suggestion: keep monitoring your process using 'top' while it 
runs. Keep a note of the memory usage. See if it dies at a consistent 
point.

I don't *think* that simply running out of memory will cause the process 
to be killed -9; malloc should fail and ruby should be able to print 
something.

-- 
Posted via http://www.ruby-forum.com/.