Luciano Moreira - igLnx wrote: > But Glynn, my applicaton is receiving SIGTERM (signal 15). Just to check, are you sure that you aren't actually receiving signal 015 (octal 15 = decimal 13 = SIGPIPE)? > I'm handling SIGPIPE also, but I never received it signal. SIGPIPE is raised if you attempt to write to a descriptor (pipe, socket) for which the other end has closed the connection. Reading from a closed socket won't raise a signal; the call will just read zero bytes (this can only occur due to EOF; reading from a socket for which no data is available will either block until data is available, or fail with EAGAIN if the socket is non-blocking, or fail with EINTR if the call was interrupted). The only common reason for receiving SIGTERM is if a process explicitly raises it with kill(), e.g. via the "kill" command. The only cases which I can find where the kernel will send SIGTERM of its own accord are: a) If the system runs out of memory, the kernel will start killing processes (out-of-memory (OOM) killer); normally, it sends SIGKILL, but if the process has the CAP_SYS_RAWIO capability, it sends SIGTERM instead. b) Certain user-space processes which are significant to the kernel (e.g. SMB/NCP FS client processes, USB khubd process, I2O event handler and LCT processes) are terminated with SIGTERM. Option a) seems unlikely, and b) is out of the question for an ordinary process. -- Glynn Clements <glynn.clements@virgin.net> - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
