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
chibi@??? Global OnLine Japan/Rakuten Communications
http://www.gol.com/
