what causes SIGTERMs?

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: linking at run time.

[nanakos]

Just check dlopen,dlclose,dlsym.I think that it should be fine with your
problem.

Best regards,
Chris.

Re: linking at run time.

[Mohan Rao A. J.]

Hi,

You can use env variable 'LD_LIBRARY_PATH', which is
a colon-separated list of directories in  which  to
search  for ELF libraries at execution-time.

or 

if you want to make your lib directory as global to search for
libraries by the loader, add an entry in /etc/ld.so.conf and run 
ldconfig.


--
Mohan


On Thu, 10 Jul 2003, John T. Williams wrote:

> Is there a way to cause an exicutable to link against a specific library at
> run time.
> 
> let me explain a little
> I'm creating a dynamic library like this
> 
> $ gcc pop3.c -o libpop3.so -shared  -I../include
> 
> then creating an exicutable like this
> 
> $ gcc main.c -o getmail -L../lib -I../include -lpop3
> 
> both work fine.
> 
> in order to run my exicutable I have been copying my libpop3.so file to
> /use/lib
> then running ldconfig
> 
> and the file exicutes fine.  but its a bit of a pain in the butt to do this
> every time I recompile the library.
> 
> I was wondering if there was any way to run my program, getmail, so that ldd
> would link it against a specified file so that I didn't have to put a
> library that I'm developing into my /usr/lib folder.  nor have to run
> ldconfig as root.
> 
> I hope this makes sense.
> 
> 
> -
> 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
> 

-- 
Mohan

linking at run time.

[John T. Williams]

Is there a way to cause an exicutable to link against a specific library at
run time.

let me explain a little
I'm creating a dynamic library like this

$ gcc pop3.c -o libpop3.so -shared  -I../include

then creating an exicutable like this

$ gcc main.c -o getmail -L../lib -I../include -lpop3

both work fine.

in order to run my exicutable I have been copying my libpop3.so file to
/use/lib
then running ldconfig

and the file exicutes fine.  but its a bit of a pain in the butt to do this
every time I recompile the library.

I was wondering if there was any way to run my program, getmail, so that ldd
would link it against a specified file so that I didn't have to put a
library that I'm developing into my /usr/lib folder.  nor have to run
ldconfig as root.

I hope this makes sense.

Re: linking at run time.

[Progga]

On Thu, Jul 10, 2003 at 02:50:48AM -0700, John T. Williams wrote:
 
> I was wondering if there was any way to run my program, getmail, so that ldd
> would link it against a specified file so that I didn't have to put a
> library that I'm developing into my /usr/lib folder.  nor have to run
> ldconfig as root.

 To link and then exec using an uninstalled lib:

 c++ -o hihi hihi_main.c++ path/libvovo.so -Wl,-rpath,path,-rpath,/usr/local/lib


 Khoda Hafez
 Progga

 

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>