Hello, On Wed, 25 Jan 2017 09:34:39 +0000 Jeremy Harris wrote:
> On 25/01/17 07:10, Christian Balzer wrote: > > I'd be happy to collect cores if this can be turned on with the existing > > binaries, but I have a feeling that the RLIMIT_CORE override is still in > > there and not changeable w/o compiling stuff, right? > > I'd love a core (even just the stacktrace, though bonus for having > library -debug packages installed). Installing those is not an issue. >I've never had an issue getting > cores on Fedora or Centos; you do need to check > > - ulimit -c Well, exim doesn't pick that up from the environment it's started from, it sets that to 0 internally. Alas this is Jessie, where the gods have finally blessed us with prlimit so: --- # ps faxvww |grep exim 10341 ? Ss 6:51 0 1093 103138 4924 0.0 /usr/sbin/exim4 -bd -q15s 4173 ? S 0:00 0 1093 103374 8748 0.1 \_ /usr/sbin/exim4 -bd -q15s [...] # prlimit --pid 10341 |grep core CORE max core file size 0 unlimited blocks # prlimit --pid 10341 --core=unlimited # prlimit --pid 10341 |grep core CORE max core file size unlimited unlimited blocks --- This is being picked up by the child processes as well. Alas no cores were forthcoming (in /var/spool/exim4/). > - /proc/sys/fs/suid_dumpable That resulted in: --- Jan 26 00:26:59 mx09 kernel: [9635416.967425] Unsafe core_pattern used with suid_dumpable=2. Pipe handler or fully qualified core dump path required. --- Fair enough, so setting: > - /proc/sys/kernel/core_pattern > to: --- # cat /proc/sys/kernel/core_pattern /var/tmp/core.%e.%p.%h.%t --- Silenced the warning but still gave me a load of silence. Cores are hard, lets go shopping? Christian -- Christian Balzer Network/Systems Engineer [email protected] Global OnLine Japan/Rakuten Communications http://www.gol.com/ -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
