Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I'm doing some stress testing of a piece of software that can run shell commands. Periodically, the system logs me out during stress testing. My record of the commands that triggered this always yields commands that run just fine on their own and do not log out.

How can I tell what triggered an unexpected logout?

Edit in response to comments:

Using: Ubuntu 12.04, x64. Shell commands are more or less arbitrary combinations of a large command set, but do not include kill or other methods for halting a process directly. Example command sequence that induces a crash:

cd /tmp
pwd
dmesg
date -u
*some internal program calls happen here*
*logout happens here*

My guess is that it's something internal to my program, so I mention the shell commands only for completeness. Running with valgrind piped to a logfile shows a clean exit, akin to what would happen if I stopped the process normally during logout. No memory leaks or invalid access issues at all. Makes it hard to figure out what's going on!

Edit2: More details after trawling through syslog. All I have is this:

Oct  1 14:39:26 my_hostname pulseaudio[7519]: [pulseaudio] pid.c: Daemon already running.
Oct  1 14:39:37 my_hostname kernel: [499969.564820] init: tty4 main process (1031) killed by TERM signal
Oct  1 14:39:37 my_hostname kernel: [499969.565018] init: tty5 main process (1037) killed by TERM signal
Oct  1 14:39:37 my_hostname kernel: [499969.565201] init: tty2 main process (1052) killed by TERM signal
Oct  1 14:39:37 my_hostname kernel: [499969.565391] init: tty3 main process (1053) killed by TERM signal
Oct  1 14:39:37 my_hostname kernel: [499969.565595] init: tty6 main process (1055) killed by TERM signal
Oct  1 14:39:37 my_hostname kernel: [499969.565798] init: cron main process (1065) killed by TERM signal
Oct  1 14:39:37 my_hostname kernel: [499969.566014] init: irqbalance main process (1120) killed by TERM signal
Oct  1 14:39:37 my_hostname kernel: [499969.566233] init: tty1 main process (1391) killed by TERM signal
Oct  1 14:39:38 my_hostname kernel: [499969.875817] init: plymouth-upstart-bridge main process (7542) terminated with status 1

and then what looks like a huge dump of kernel messages also at 14:38:37 that look like the system resetting itself prior to login.

share|improve this question
    
Hi we need some more info other than this. What is the flavor of linux you are using (is it linux mint, ubuntu etc)? Also, give an example of the shell commands that are being run in the back ground . –  The Dark Knight Oct 1 '12 at 12:00
    
That's a good question, killed by SIGNTERM is normal I guess, did you enabled auto-update? –  warl0ck Oct 1 '12 at 13:25
    
@warl0ck: No, updates are done manually. Also, this happens several times per hour when stress testing, and only when stress testing. –  John Doucette Oct 1 '12 at 13:35
    
What happens after the log messages you posted? Does the system reboot? It looks like something told init to reboot, but it's difficult to tell with only the information you provided. –  Gilles Oct 1 '12 at 23:30
    
The system logs out. The logfile looks like a reboot, but software only. The hardware seems happy enough and I don't get kicked to the bios. –  John Doucette Oct 2 '12 at 9:01
show 1 more comment

1 Answer

up vote 3 down vote accepted

It depends on, what type of stress test you are doing. When the kernel doesn't have enough resources to continue, random process are killed. This happens only on realy high loads, for example when you don't have a pagefile and all your memory is used in some processes.

share|improve this answer
    
Does it really kill random processes? If so, this could explain quite a lot of strange behaviors I've been seeing. –  John Doucette Oct 1 '12 at 16:01
1  
There is an algorithm for selecting candidates but it depends on some non-deterministic external inputs (e.g. which processes are running and what they are doing) and unless you really understand the whole mechanism, it may as well be random. –  jw013 Oct 1 '12 at 17:07
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.