Re: what causes SIGTERMs?

Re: what causes SIGTERMs?

[Jad Saklawi]

Hello,
check out on http://www.advancedlinuxprogramming.com/alp-folder
i think it is in chapter 3 of the book, all about signals.

why not try out using http://syscalltrack.sourceforge.net and see what is 
causing the signal
                                              Greets, Jad
Quoting Matthew Studley <matthew.studley@uwe.ac.uk>:

> Hi all
> 
> thanks for the help regarding linux signals... very useful!
> 
> I have written this little test program, which I then send a SIGTERM using
> another process.
> (I've been testing this under the current stable release of Debian)
> 
> I notice that, while siginfo_t.si_signo seems to have a meaningful value,
> all other fields e.g. si_pid are ZERO !
> 
> Does anybody have any ideas about this?
> 
> cheers Matt
> 
> ============================================
> 
> 
> #include <signal.h>
> #include <stdio.h>
> 
> /*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> */
> void myHandler(int i, siginfo_t *info, void *v){
>   printf("i = %d\n", i);
>   printf("signo is %d\n", info->si_signo);
>   printf("calling pid is %d\n", info->si_pid);
>   printf("calling uid is %d\n", info->si_uid);
>   printf("errno : %d\n", info->si_errno);
>   printf("code : %d\n", info->si_code);
>   fflush(stdout);
> }
> /*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> */
> int main(void){
>   int i;
>   struct sigaction mySigaction;
> 
>   mySigaction.sa_sigaction = (myHandler);
>   sigemptyset (&mySigaction.sa_mask);
>   mySigaction.sa_flags = SA_SIGINFO;      //SA_RESTART | SA_SIGINFO;
>   if(sigaction(SIGTERM, &mySigaction, NULL) < 0) {
>   perror("ERROR: registering Handler Function\n");
>   exit(1);
>   }
> 
>   while(1){
>     // do nothing.
>   }
> }
> /*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> */
> 
> ========
> >
> > Matthew Studley wrote:
> >
> > > I wonder whether you could help me?  I have a problem; I'm running an
> > > application I've written in C under Slackware 7.1  Occasionally it
> receives
> > > a SIGTERM.
> > >
> > > * In what circumstances do processes get sent a SIGTERM?
> >
> > If something raises it with kill(). Note that SIGTERM is the default
> > signal sent by the kill and killall commands.
> >
> > > * Am I correct that this is unlikely to be issued in response to a bug
> in my
> > > code?
> >
> > Correct. SIGTERM isn't sent synchronously (i.e. in response to the
> > actions of the process which receives it).
> >
> > > * How can I find which process is issuing the SIGTERM against my code?
> >
> > Install a signal handler using sigaction() with the SA_SIGINFO flag;
> > the sending process ID will be in the si_pid field of the siginfo_t
> > structure. Other fields of that structure may also contain useful
> > information.
> >
> > --
> > Glynn Clements <glynn.clements@virgin.net>
> >
> >
> 
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-c-programming" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

what causes SIGTERMs?

[Matthew Studley]

Hi All

I wonder whether you could help me?  I have a problem; I'm running an
application I've written in C under Slackware 7.1  Occasionally it receives
a SIGTERM.

* In what circumstances do processes get sent a SIGTERM?

* Am I correct that this is unlikely to be issued in response to a bug in my
code?

* How can I find which process is issuing the SIGTERM against my code?

* Are there any changes I can make to the execution environment / logging /
gcc compilation options to help me find out why this is happening?

If anybody can give me some ideas, or suggest directions to investigate, I'd
be hugely thankful!

Just as a bit of background; the platform is a robot on which I have
recently fitted some new hardware.  The SIGTERM problem started at roughly
the same time.  If I catch the SIGTERM, and do nothing apart from continue
my application... I then catch more SIGTERMs, followed by a SIGKILL!

regards

Matt

==============================================
Matthew Studley

The Intelligent Computer Systems Centre
Faculty of Computing, Engineering and Mathematical Sciences
Coldharbour Lane, Frenchay
BS16 1QY
United Kingdom

Re: what causes SIGTERMs?

[Francis Lau]

A link that gives a simple explanation on what SIGTERM and SIGKILL mean:
http://www.gnu.org/manual/glibc-2.2.5/html_node/Termination-Signals.html

> 
> I wonder whether you could help me?  I have a problem; I'm running an
> application I've written in C under Slackware 7.1  Occasionally it receives
> a SIGTERM.
> 
> * In what circumstances do processes get sent a SIGTERM?
> 
> * Am I correct that this is unlikely to be issued in response to a bug in my
> code?
> 
> * How can I find which process is issuing the SIGTERM against my code?

Perhaps use strace or gdb to see where the code is dying?

> 
> * Are there any changes I can make to the execution environment / logging /
> gcc compilation options to help me find out why this is happening?

compiel with -g for more debugging information

Hope it helps,

Francis

Re: what causes SIGTERMs?

[Glynn Clements]

Matthew Studley wrote:

> I wonder whether you could help me?  I have a problem; I'm running an
> application I've written in C under Slackware 7.1  Occasionally it receives
> a SIGTERM.
> 
> * In what circumstances do processes get sent a SIGTERM?

If something raises it with kill(). Note that SIGTERM is the default
signal sent by the kill and killall commands.

> * Am I correct that this is unlikely to be issued in response to a bug in my
> code?

Correct. SIGTERM isn't sent synchronously (i.e. in response to the
actions of the process which receives it).

> * How can I find which process is issuing the SIGTERM against my code?

Install a signal handler using sigaction() with the SA_SIGINFO flag;
the sending process ID will be in the si_pid field of the siginfo_t
structure. Other fields of that structure may also contain useful
information.

-- 
Glynn Clements <glynn.clements@virgin.net>

Re: what causes SIGTERMs?

[Matthew Studley]

Hi all

thanks for the help regarding linux signals... very useful!

I have written this little test program, which I then send a SIGTERM using
another process.
(I've been testing this under the current stable release of Debian)

I notice that, while siginfo_t.si_signo seems to have a meaningful value,
all other fields e.g. si_pid are ZERO !

Does anybody have any ideas about this?

cheers Matt

============================================


#include <signal.h>
#include <stdio.h>

/*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */
void myHandler(int i, siginfo_t *info, void *v){
  printf("i = %d\n", i);
  printf("signo is %d\n", info->si_signo);
  printf("calling pid is %d\n", info->si_pid);
  printf("calling uid is %d\n", info->si_uid);
  printf("errno : %d\n", info->si_errno);
  printf("code : %d\n", info->si_code);
  fflush(stdout);
}
/*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */
int main(void){
  int i;
  struct sigaction mySigaction;

  mySigaction.sa_sigaction = (myHandler);
  sigemptyset (&mySigaction.sa_mask);
  mySigaction.sa_flags = SA_SIGINFO;      //SA_RESTART | SA_SIGINFO;
  if(sigaction(SIGTERM, &mySigaction, NULL) < 0) {
  perror("ERROR: registering Handler Function\n");
  exit(1);
  }

  while(1){
    // do nothing.
  }
}
/*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */

========
>
> Matthew Studley wrote:
>
> > I wonder whether you could help me?  I have a problem; I'm running an
> > application I've written in C under Slackware 7.1  Occasionally it
receives
> > a SIGTERM.
> >
> > * In what circumstances do processes get sent a SIGTERM?
>
> If something raises it with kill(). Note that SIGTERM is the default
> signal sent by the kill and killall commands.
>
> > * Am I correct that this is unlikely to be issued in response to a bug
in my
> > code?
>
> Correct. SIGTERM isn't sent synchronously (i.e. in response to the
> actions of the process which receives it).
>
> > * How can I find which process is issuing the SIGTERM against my code?
>
> Install a signal handler using sigaction() with the SA_SIGINFO flag;
> the sending process ID will be in the si_pid field of the siginfo_t
> structure. Other fields of that structure may also contain useful
> information.
>
> --
> Glynn Clements <glynn.clements@virgin.net>
>
>

Re: what causes SIGTERMs?

[Glynn Clements]

Matthew Studley wrote:

> thanks for the help regarding linux signals... very useful!
> 
> I have written this little test program, which I then send a SIGTERM using
> another process.
> (I've been testing this under the current stable release of Debian)
> 
> I notice that, while siginfo_t.si_signo seems to have a meaningful value,
> all other fields e.g. si_pid are ZERO !

Odd; it works for me (RedHat 6.2, Linux 2.4.21, glibc 2.1.3):

	i = 15
	signo is 15
	calling pid is 4855
	calling uid is 500
	errno : 0
	code : 0

-- 
Glynn Clements <glynn.clements@virgin.net>

Re: what causes SIGTERMs?

[Matthew Studley]

A brief follow-up

> > > * Am I correct that this is unlikely to be issued in response to a bug
> in my
> > > code?

As it turns out, this was issued in response to a runaway memory leak in my
code.  Still not sure where the signal came from.

regrds, and thanks again for all your help

matt


----- Original Message -----
From: Matthew Studley <matthew.studley@uwe.ac.uk>
To: <linux-c-programming@vger.kernel.org>
Sent: Wednesday, July 09, 2003 4:36 PM
Subject: Re: what causes SIGTERMs?


> Hi all
>
> thanks for the help regarding linux signals... very useful!
>
> I have written this little test program, which I then send a SIGTERM using
> another process.
> (I've been testing this under the current stable release of Debian)
>
> I notice that, while siginfo_t.si_signo seems to have a meaningful value,
> all other fields e.g. si_pid are ZERO !
>
> Does anybody have any ideas about this?
>
> cheers Matt
>
> ============================================
>
>
> #include <signal.h>
> #include <stdio.h>
>
> /*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
*/
> void myHandler(int i, siginfo_t *info, void *v){
>   printf("i = %d\n", i);
>   printf("signo is %d\n", info->si_signo);
>   printf("calling pid is %d\n", info->si_pid);
>   printf("calling uid is %d\n", info->si_uid);
>   printf("errno : %d\n", info->si_errno);
>   printf("code : %d\n", info->si_code);
>   fflush(stdout);
> }
> /*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
*/
> int main(void){
>   int i;
>   struct sigaction mySigaction;
>
>   mySigaction.sa_sigaction = (myHandler);
>   sigemptyset (&mySigaction.sa_mask);
>   mySigaction.sa_flags = SA_SIGINFO;      file://SA_RESTART | SA_SIGINFO;
>   if(sigaction(SIGTERM, &mySigaction, NULL) < 0) {
>   perror("ERROR: registering Handler Function\n");
>   exit(1);
>   }
>
>   while(1){
>     // do nothing.
>   }
> }
> /*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
*/
>
> ========
> >
> > Matthew Studley wrote:
> >
> > > I wonder whether you could help me?  I have a problem; I'm running an
> > > application I've written in C under Slackware 7.1  Occasionally it
> receives
> > > a SIGTERM.
> > >
> > > * In what circumstances do processes get sent a SIGTERM?
> >
> > If something raises it with kill(). Note that SIGTERM is the default
> > signal sent by the kill and killall commands.
> >
> > > * Am I correct that this is unlikely to be issued in response to a bug
> in my
> > > code?
> >
> > Correct. SIGTERM isn't sent synchronously (i.e. in response to the
> > actions of the process which receives it).
> >
> > > * How can I find which process is issuing the SIGTERM against my code?
> >
> > Install a signal handler using sigaction() with the SA_SIGINFO flag;
> > the sending process ID will be in the si_pid field of the siginfo_t
> > structure. Other fields of that structure may also contain useful
> > information.
> >
> > --
> > Glynn Clements <glynn.clements@virgin.net>
> >
> >
>
> -
> To unsubscribe from this list: send the line "unsubscribe
linux-c-programming" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>

Re: what causes SIGTERMs?

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 844 bytes --]

On Tue, 2003-07-22 15:54:04 +0100, Matthew Studley <matthew.studley@uwe.ac.uk>
wrote in message <008101c35061$18aebb20$caba0ba4@uwe.ac.uk>:
> A brief follow-up
> 
> > > > * Am I correct that this is unlikely to be issued in response to a bug
> > in my
> > > > code?
> 
> As it turns out, this was issued in response to a runaway memory leak in my
> code.  Still not sure where the signal came from.

So, most probably you got SIGTERMinated by the kernel at some
out-of-memory situation after you grew too large...

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
      ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: what causes SIGTERMs?

[Glynn Clements]

Jan-Benedict Glaw wrote:

> > > > > * Am I correct that this is unlikely to be issued in response to a bug
> > > in my
> > > > > code?
> > 
> > As it turns out, this was issued in response to a runaway memory leak in my
> > code.  Still not sure where the signal came from.
> 
> So, most probably you got SIGTERMinated by the kernel at some
> out-of-memory situation after you grew too large...

If the kernel kills a process for exhausting system memory, it
normally does so using SIGKILL. However, it will use SIGTERM if the
process has the CAP_SYS_RAW_IO capability.

If a process attempts to exceed its data segment allocation
(RLIMIT_DATA), brk() (and thus malloc() etc) will simply fail. If the
process doesn't check the return value from e.g. malloc(), it will
typically receive SIGSEGV from dereferencing NULL.

If a process attempts to exceed its data stack segment allocation
(RLIMIT_STACK), the stack won't be extended, so the process will
receive SIGSEGV from writing below the end of the stack.

If a process exceeds its CPU allocation (RLIMIT_CPU), SIGKILL is used.

So, the most likely reason is that the kernel's OOM-killer decided to
terminate your process to obtain some more memory. This isn't strictly
a synchronous signal, in that it isn't necessarily sent to the process
which is causing the problem.

If the kernel is having difficulty obtaining memory, it will start
killing off processes according to various criteria. One of these is
the amount of memory which the process uses, so in the case of a
single runaway process causing the shortage, the same process is
likely to be killed.

However, if you had caught the SIGTERM, and didn't terminate quickly
enough, the kernel may have started killing other processes in order
to satisfy its memory requirements.

-- 
Glynn Clements <glynn.clements@virgin.net>