On Oct 12, 2009 at 10:54, inge <inge(a)legos.fr> wrote:
A command issued by the FIFO can lead to a restart of
how we see in the
logs "messages" ?
If "kill" is sent over the fifo, you will see only one of the DBG()s:
"SIGTERM received, program terminates". Note that you will see it in the
log only if debug>4, or if you replace it with a LOG(L_CRIT, ...).
Andrei
Le lundi 12 octobre 2009 ?? 10:47 +0200, Andrei Pelinescu-Onciul a
??crit :
> On Oct 12, 2009 at 09:57, inge <inge(a)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