On 19/03/2015 13:35, Markus Sch?nhaber wrote:>> dumped". If I put "abort()" in the code at the point it is reporting >> then a core file is written, so there is no OS reason why a core can not >> be written. It appears to be dovecot's choice to control the child. In >> an attempt to obtain a core file I have: >> >> service imap-login { >> chroot >> drop_priv_before_exec = yes >> user = dovecot >> } >> >> How can I make imap-login to produce a core file? > > Maybe this helps: > http://dovecot.org/bugreport.html#coredumpsI can create core dumps but not from imap-login, so it's not a general system restriction. Adding abort() to the master gives a core - but but not a relevant one. Adding an arbitrary abort() to imap-login gives a "core not dumped" message. James.
On 03/19/2015 02:53 PM, James wrote:>>> ... >>> service imap-login { >>> chroot >>> drop_priv_before_exec = yes >>> user = dovecot >>> } >>> >>> How can I make imap-login to produce a core file? > ... > I can create core dumps but not from imap-login, so it's not a general > system restriction. Adding abort() to the master gives a core - but but > not a relevant one. Adding an arbitrary abort() to imap-login gives a > "core not dumped" message.Try this configuration: service imap-login { executable = imap-login -D } Your configuration (doveconf -n output) may be also helpfull Regards, Pascal -- The trapper recommends today: defaced.1507821 at localdomain.org
On 19/03/2015 20:59, Pascal Volk wrote:> Try this configuration: > > service imap-login { > executable = imap-login -D > }Many thanks, Pascal. That did it. Now I have a core I can investigate the real problem - it's openssl that is failing, ha, maybe the problem will just go away with openssl 1.0.2a. James.