Hi People ! Hi Glynn !
Finally I found a bug. I was printing received signal thus:
printf("\nSIGNAL: STOPING APP (%d %s)\n", sig,
(sig=SIGTERM) ?"SIGTERM" :
((sig=SIGABRT) ?"SIGABRT" :
((sig=SIGINT) ?"SIGINT" :"<undefined>"))
);
Setting the signal as SIGTERM, because I was using "=" instead "==".
Thank you very much, for help me to find the bug.
Luciano Moreira
----- Original Message -----
From: "Glynn Clements" <glynn.clements@virgin.net>
To: "Luciano Moreira - igLnx" <lucianolnx@ig.com.br>
Cc: <linux-net@vger.kernel.org>
Sent: Tuesday, March 25, 2003 10:39 PM
Subject: Re: SOCKETS, signal(), pthread???() and mutex???() - PROBLEMS
>
> 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
>
>
-
: 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
