Hello,
Despite this fix
https://github.com/sipwise/rtpengine/commit/cbe1f805363b3d6a117e9e5425d79943...
I am continuing to experience periodic crash problems under high loads with rtpengine. This is after upgrading mediaproxy-ng -> rtpengine.
Unfortunately, after this upgrade, it is impossible to tell the cause of the crash because the [seemingly] newer rtpengine SIGABRT and/or crash handler is not running properly and is getting in my way:
Jun 20 15:47:55 rtphost abrtd: Directory 'ccpp-2014-06-20-15:47:54-1123' creation detected Jun 20 15:47:55 rtphost abrt[2159]: Saved core dump of pid 1123 (/usr/sbin/rtpengine) to /var/spool/abrt/ccpp-2014-06-20-15:47:54-1123 (97013760 bytes) Jun 20 15:47:55 rtphost abrtd: Executable '/usr/sbin/rtpengine' doesn't belong to any package and ProcessUnpackaged is set to 'no' Jun 20 15:47:55 rtphost abrtd: 'post-create' on '/var/spool/abrt/ccpp-2014-06-20-15:47:54-1123' exited with 1 Jun 20 15:47:55 rtphost abrtd: Deleting problem directory '/var/spool/abrt/ccpp-2014-06-20-15:47:54-1123'
I am not sure why this script is exiting, but the result is that I have no /var/spool/abrt/ccpp-2014-06-20-15:47:54-1123 and no core dump to work with. This is on a standard minimal CentOS 6.5.x install.
Is there any way to either disable this signal handler and just let it dump core normally, or, otherwise, to definitively fix the crash handler?
Thanks,
On 06/21/14 18:19, Alex Balashov wrote:
This is not something that rtpengine is doing. You'd have to look within your system installation/distribution, possibly here:
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/...
cheers
On 06/21/2014 10:01 PM, Richard Fuchs wrote:
Thanks for that, Richard. I was not aware that this was something done by the surrounding environment.
The core file is usually stored in the working directory where the executable was invoked.
Regards, Carlos
On Sun, Jun 22, 2014 at 9:28 AM, Alex Balashov abalashov@evaristesys.com wrote:
On 06/22/2014 10:59 AM, Carlos Ruiz Díaz wrote:
The core file is usually stored in the working directory where the executable was invoked.
Yeah, if it's not being caught and then mishandled by a specious endeavuor like ABRT, conceived by cretins and imbeciles.
I've been through the same problem some time ago, even with the same misleading syslog message. Turned out the core file was not where the logs said they were put, but in the exact working directory where I manually started the service.
Try running rtpengine without the init.d scripts. Rtpengine has its way of daemonizing itself anyway.
If you are unlucky even after doing this, maybe a standard shell find could help you.
# find / -name core.<pid-reported-in-the-logs> -type f # find / -name core.1123 -type f
On Sun, Jun 22, 2014 at 10:01 AM, Alex Balashov abalashov@evaristesys.com wrote:
On 06/22/2014 11:15 AM, Carlos Ruiz Díaz wrote:
I looked, but unfortunately it's not there.
Try running rtpengine without the init.d scripts. Rtpengine has its way of daemonizing itself anyway.
I already do that.
Yep, other core files from previous mediaproxy-ng crashes are in the working directory of invocation. But not this one. And it's this one that I really need.
I guess I'll just wait for next time. Of course, I did disable 'abrtd' entirely. I hope whoever came up with this shit takes a warm piss on a high-amperage power line.
This ABRT service is one of the stupidest things I've ever heard of.
Whoever conceived of this scourge, and other futile and misguided attempts to speciously "automate" things that have worked just fine for decades, should burn in a special circle of hell. Neither I nor anyone else need a "core dump management system". Where do people come up with this inane filth? I am forced to conclude that modern Linux distribution architects have all undergone a transorbital lobotomy. You know, the icepick-looking thing stabbed into the corner of their eye...
-
Alex Balashov -
Carlos Ruiz Díaz -
Richard Fuchs