[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-net
Subject:    Re: SOCKETS, signal(), pthread???() and mutex???() - PROBLEMS
From:       "Luciano Moreira - igLnx" <lucianolnx () ig ! com ! br>
Date:       2003-03-26 17:08:57
[Download RAW message or body]

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>
> -
> To unsubscribe from this list: 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
> 
> 

-
To unsubscribe from this list: 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
[prev in list] [next in list] [prev in thread] [next in thread]