Hi Chuck, Try: dmesg | grep 'oom-killer' and see if anything pops out.
To run inside gdb, install screen and then: $ screen gdb --args memcached <options> (gdb) run [type ctrl-A D] this will run memcached inside a detached screen session. When memcached has died, run "screen -dr" from the same user and type "bt". This will generate a backtrace which will be helpful for diagnosing the crash. N.B.: if memcached crashes while inside gdb, it may well leave the listening socket open but not responding - this will be a different failure behavior than you'll see when running memcached not in gdb, and might hose your application if it doesn't handle timeouts correctly. -Todd On Thu, Jan 15, 2009 at 9:00 PM, Chuck Weinstock <[email protected]> wrote: > > I admit to not having a clue how to run it within gdb (and still get > output that can be analyzed if it crashes). > > The machine has not rebooted. We do not have automated tools to kill > "big" processes but I have not seen such. Finally I am not sure which > logs to look at or how to get an idea of when the death occurs. > > Sorry to be such a novice about this. > > Chuck > > On Jan 14, 12:27 pm, Dustin <[email protected]> wrote: > > On Jan 13, 6:33 pm, Chuck Weinstock <[email protected]> wrote: > > > > > We invoke it with "memcached -d -p 11211 -u nobody -c 1024 -m 512". > > > The way we tell it is crashed is that a "ps aux | grep memcached" does > > > not show a process running memcached. > > > This was compiled from source. > > > > > I have no idea what else to do? > > > > Can you run it from within gdb so that when it stops we can at least > > see why (assuming it is crashing)? I'd really like to know why it's > > failing for you, but there's not a lot to go by here. > > > > Has the machine rebooted? > > > > Do you have any automated tools to kill "big" processes? > > > > Are there any logs near these death events that might be useful? >
