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.

My server program received a SIGTERM and stopped (with exit code 0). I am surprised by this, as I am pretty sure that there was plenty of memory for it. Under what conditions does linux (busybox) send a SIGTERM to a process?

share|improve this question
    
I can't think of any case when the kernel or a standard tool would send SIGTERM to a random process. What can you tell us about what the program is doing and how it's started? How did you find out about the program's exit status? Can you reproduce the problem? Do you have logs you can check? –  Gilles Mar 28 '11 at 17:57
    
It is reading and writing to a serial line, and is responding to UDP and TCP requests. I have wrapped the execution on a bash script and therefore I know the exit code. –  michelemarcon Mar 29 '11 at 8:14
1  
Posix documentation indicates SIGTERM is strictly a user level event. Is it possible someone else was able to kill your server program? –  shellter Mar 29 '11 at 22:48
    
Very unlikely; however, all I know is the return code (0) which is the same that I get when I terminate the process with ^C (SIGTERM). Maybe I'm overlooking something? –  michelemarcon Mar 30 '11 at 7:05
2  
You are! The return code 0 means a normal exit. If there was a SIGTERM, $? would be set to 143 (128 + signal number). –  Gilles Mar 30 '11 at 18:36
add comment

3 Answers

up vote 4 down vote accepted

I'll post this as an answer so that there's some kind of resolution if this turns out to be the issue.

An exit status of 0 means a normal exit from a successful program. An exiting program can choose any integer between 0 and 255 as its exit status. Conventionally, programs use small values. Values 126 and above are used by the shell to report special conditions, so it's best to avoid them.

At the C API level, programs report a 16-bit status¹ that encodes both the program's exit status and the signal that killed it, if any.

In the shell, a command's exit status (saved in $?) conflates the actual exit status of the program and the signal value: if a program is killed by a signal, $? is set to a value greater than 128 (on every unix I know, this value is 128 plus the signal number).

In particular, if $? is 0, your program exited normally.

¹ roughly speaking

share|improve this answer
add comment

kernel can generate SIGTERM when running low on disk space or there is a hardware interrupt...caused by some error

share|improve this answer
    
No, it doesn't. What makes you think it might? –  Gilles Mar 29 '11 at 18:34
add comment

Are you sure it exited on SIGTERM? The kernel nor busybox would never generate this normally. If the program actually exited on a signal, it would not have an exit code unless you caught the signal and did a normal exit. You mentioned working with serial ports and sockets, it is possibly that it's a SIGPIPE that's killing it? Or possibly a SIGINT due to receiving a Control-C over the serial port?

share|improve this answer
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.