Did some digging, and I did find this article: http://blog.tinola.com/?e=36
It could be related to the issue you are experiencing, especially since just before the SIGABRT, the process is trying to do a hostname resolution, but can’t, because it’s in a chroot (the reason you get all the No such file or directory responses, is because they don’t exist in the chroot). If you remove the “chroot xxx” line from your haproxy config, does the problem go away? With the time frames being exactly 4 hours apart, is it possible you have some external software (monitors or the like?) that hits the server every 4 hours? Thanks! Dan Dubovik Senior Linux Systems Engineer From: David Adams <[email protected]<mailto:[email protected]>> Reply-To: David Adams <[email protected]<mailto:[email protected]>> Date: Thursday, December 11, 2014 at 7:08 PM To: Lukas Tribus <[email protected]<mailto:[email protected]>>, Tait Clarridge <[email protected]<mailto:[email protected]>> Cc: HAproxy Mailing Lists <[email protected]<mailto:[email protected]>> Subject: Re: 1.5.9 crashes every 4 hours, like clockwork I ran strace on it just before CRASHTIME. It stopped on cue, with an exit code of 134. The strace output is here: haproxy strace - Pastebin.com<http://pastebin.com/VLxwDDwj> As you'll see, it looks very strange - immediately after a series of futex calls (I've no idea of their significance, only noting that they don't appear in the strace at other times) then system returns a number of "No such file or directory" errors on a variety of system files, despite them being present before and after. Despite setting the ulimit in the session before starting haproxy no coredump was generated. I notice I can deploy haproxy without futex support. Is that worth a try? Many thanks to all those helping me sort this out. On Thursday, 11 December 2014, 17:45, Lukas Tribus <[email protected]<mailto:[email protected]>> wrote: > I will do next time. And yes, was planning to run strace. > > Do I need to recompile to enable coredumps? No, you just adjust ulimit before you start, and make sure you didn't strip (as in the command strip) the executable. Then check the core with: gdb path/to/the/binary path/to/the/core and to something like bt or bt full (within gdb). Regards, Lukas
