[sr-dev] SER crash : Segmentation fault

[inge]

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".

About the "dmesg | grep 00M", I have no output generated by this
command.

Regards,

Adrien.

Le vendredi 09 octobre 2009 à 20:59 +0200, Andrei Pelinescu-Onciul a
écrit :
> On Oct 09, 2009 at 20:33, inge <inge at legos.fr> wrote:
> > Hello Andrei,
> > 
> > We are now running to 0.9.9+cvs20090925 since 10 days.
> > 
> > Today SER crash/stop without coredump. Do you know if we need to
> > configure something for enable this option ?
> 
> No, coredump it's enabled by default since 0.9.3.
> However note that if you don't start ser as root, it cannot enable
> core-dumping (and you have to do it b by hand before starting ser).
> Note also that even if started as root, if it's supposed to change its
> uid (e.g. started with -u <some_user> or with uid in the .cfg) it won't
> be able to dump core on any modern linux kernel (in this case you would
> need to set /proc/sys/fs/suid_dumpable to 1 or remove the -u from ser
>  command line).
> 
> You can check if it dumps core, by sending SIGABRT to one of the ser
> processes (e.g kill -SIGABRT <pid_of_ser>).
> > 
> > With the previous crash, we got in /var/log/messages something like a
> > CHILD which firstly crashed and then all the processes are followed. But
> > here SER stop like "service ser stop" by printing only in the log
> > "INFO : signal 15 received..."
> > 
> > Do you have any idea ?
> 
> Are you sure somebody hasn't stopped it?
> If it crashed and couldn't dump core, there should be a message logged
> (something like ... core was not generated...). Also you should see
> messages about the signal that caused the first child process to
> terminate and if it's really a problem it will be different from 15.
> 
> Another possibility is that the kernel killed some ser processes due to
>  low memory (check dmesg for OOM).
> 
> 
> Andrei
-------------- next part --------------
Oct  9 18:26:27 solo /usr/local/sbin/ser[6821]: get_to_tag(): To header field missing
Oct  9 18:26:27 solo /usr/local/sbin/ser[6821]: ERROR: unforce_rtp_proxy: can't get To tag
Oct  9 18:26:27 solo /usr/local/sbin/ser[6851]: INFO: signal 15 received
Oct  9 18:26:27 solo /usr/local/sbin/ser[6857]: INFO: signal 15 received
Oct  9 18:26:27 solo /usr/local/sbin/ser[6858]: INFO: signal 15 received
Oct  9 18:26:27 solo /usr/local/sbin/ser[6852]: INFO: signal 15 received
Oct  9 18:26:27 solo /usr/local/sbin/ser[6855]: INFO: signal 15 received
Oct  9 18:26:27 solo /usr/local/sbin/ser[6832]: INFO: signal 15 received
Oct  9 18:26:27 solo /usr/local/sbin/ser[6826]: INFO: signal 15 received
Oct  9 18:26:27 solo /usr/local/sbin/ser[6827]: INFO: signal 15 received
Oct  9 18:26:27 solo /usr/local/sbin/ser[6854]: INFO: signal 15 received
Oct  9 18:26:27 solo /usr/local/sbin/ser[6838]: INFO: signal 15 received
Oct  9 18:26:27 solo /usr/local/sbin/ser[6824]: INFO: signal 15 received
Oct  9 18:26:27 solo /usr/local/sbin/ser[6856]: INFO: signal 15 received
Oct  9 18:26:27 solo /usr/local/sbin/ser[6823]: INFO: signal 15 received
Oct  9 18:26:27 solo /usr/local/sbin/ser[6822]: INFO: signal 15 received
Oct  9 18:26:27 solo /usr/local/sbin/ser[6818]: INFO: signal 15 received
Oct  9 18:26:27 solo /usr/local/sbin/ser[6850]: INFO: signal 15 received
Oct  9 18:26:27 solo /usr/local/sbin/ser[6849]: INFO: signal 15 received
Oct  9 18:26:27 solo /usr/local/sbin/ser[6848]: INFO: signal 15 received
Oct  9 18:26:27 solo /usr/local/sbin/ser[6817]: INFO: signal 15 received
Oct  9 18:26:27 solo /usr/local/sbin/ser[6847]: INFO: signal 15 received
Oct  9 18:26:27 solo /usr/local/sbin/ser[6814]: INFO: signal 15 received
Oct  9 18:26:27 solo /usr/local/sbin/ser[6846]: INFO: signal 15 received
Oct  9 18:26:27 solo /usr/local/sbin/ser[6845]: INFO: signal 15 received
Oct  9 18:26:27 solo /usr/local/sbin/ser[6844]: INFO: signal 15 received
Oct  9 18:26:27 solo /usr/local/sbin/ser[6842]: INFO: signal 15 received
Oct  9 18:26:27 solo /usr/local/sbin/ser[6840]: INFO: signal 15 received
Oct  9 18:26:27 solo /usr/local/sbin/ser[6839]: INFO: signal 15 received
Oct  9 18:26:27 solo /usr/local/sbin/ser[6837]: INFO: signal 15 received
Oct  9 18:26:27 solo /usr/local/sbin/ser[6836]: INFO: signal 15 received
Oct  9 18:26:27 solo /usr/local/sbin/ser[6835]: INFO: signal 15 received
Oct  9 18:26:27 solo /usr/local/sbin/ser[6834]: INFO: signal 15 received
Oct  9 18:26:27 solo /usr/local/sbin/ser[6831]: INFO: signal 15 received
Oct  9 18:26:27 solo /usr/local/sbin/ser[6830]: INFO: signal 15 received
Oct  9 18:26:27 solo /usr/local/sbin/ser[6828]: INFO: signal 15 received
Oct  9 18:26:27 solo /usr/local/sbin/ser[6820]: INFO: signal 15 received
Oct  9 18:26:27 solo /usr/local/sbin/ser[6819]: INFO: signal 15 received
Oct  9 18:26:27 solo /usr/local/sbin/ser[6816]: INFO: signal 15 received
Oct  9 18:26:27 solo /usr/local/sbin/ser[6815]: INFO: signal 15 received
Oct  9 18:26:27 solo /usr/local/sbin/ser[6825]: INFO: signal 15 received
Oct  9 18:26:27 solo /usr/local/sbin/ser[6821]: INFO: signal 15 received
Oct  9 18:26:27 solo /usr/local/sbin/ser[6853]: INFO: signal 15 received
Oct  9 18:26:27 solo /usr/local/sbin/ser[6829]: INFO: signal 15 received
Oct  9 18:26:27 solo /usr/local/sbin/ser[6843]: INFO: signal 15 received
Oct  9 18:26:27 solo /usr/local/sbin/ser[6833]: INFO: signal 15 received
Oct  9 18:26:27 solo /usr/local/sbin/ser[6812]: CHECK_UA - destroing module