[sr-dev] SER crash : Segmentation fault

inge inge at legos.fr
Mon Oct 12 10:54:11 CEST 2009


A command issued by the FIFO can lead to a restart of how we see in the
logs "messages" ?

Regards,

Adrien.

Le lundi 12 octobre 2009 à 10:47 +0200, Andrei Pelinescu-Onciul a
écrit :
> On Oct 12, 2009 at 09:57, inge <inge at legos.fr> wrote:
> > Hello Andrei,
> > 
> > Thank for having replied.
> > 
> > SER runs as root user without anything in the config file concerning a
> > "-u" option, even in a "ps aux", all the process are started without
> > options.
> > 
> > We have checked and it seems that no one shoot the process at the time
> > crash happened.
> > 
> > I attached to this email the /var/log/messages. As you will see, we just
> > received a "signal 15".
> 
> If it would have been a process that crashed or exited (which would be
> another bug), you would have in the log one of the following lines:
> child process %d exited normally, status=
> child process %d exited by a signal 
> child process %d stopped by a  signal
> 
> After that you would have another line:
> INFO: terminating due to SIGCHLD
> 
> (see main.c:506 , in handle_sigs()).
> 
> The log fragment you sent, shows that log messages with L_INFO are
> printed (so debug>=L_INFO) => you should see one of the above lines.
> 
> If you don't see them the only explanation is that someone or some other
> program sent a SIGTERM or SIGINT to it.
> There is a message printed any time the main program gets a SIGTERM, but
> its printed only on high debug levels. You could try either increasing
> the debug level (,e.g. debug=5, but then you'll have a _lot_ logged) or
> changing
>  main.c:478: DBG("SIGTERM received, program terminates\n"); to
>   LOG(L_CRIT, "SIGTERM received, program terminates\n"); 
>   and main.c:476    DBG("INT received, program terminates\n");
> to LOG(L_CRIT, "INT received, program terminates\n");.
> 
> This way if it happens a second time you'll at least see if the main
> process was manually killed (which is the only explanation I can offer).
> 
> Andrei




More information about the sr-dev mailing list