Isn't the version I have (2.0.9) newer than 2.0.19? The newest RPM I could find for CentOS was dovecot-2.0.9-2, not all that much newer than what I am using. I am not opposed to upgrading, just not sure if I am seeing much in the way of RPMs for my system that I can use to upgrade to a version that is much newer than what I already have.
I had taken the " echo 'DAEMON_COREFILE_LIMIT="unlimited"' >> /etc/sysconfig/dovecot" command from the Dovecot page on enabling core dumps for Red Hat (http://www.dovecot.org/bugreport.html). I have also added unlimited core dump files to /etc/security/limits.conf and verified that whenever myself or anyone else opens a shell that "ulimit -c" shows an output of "unlimited".
I don't see any mention of limits in my Dovecot init file either. The init script came with my RPM package and I have not modified it.
Even though I have unlimited core dump files allowed, I am still getting core files that are 0 bytes in size in the mail user's home directory. Any idea why?
[root@imapserver ~]# su - dovecot -bash-3.2$ ulimit -c unlimited -bash-3.2$ id uid=97(dovecot) gid=97(dovecot) groups=97(dovecot)
[root@imapserver ~]# service dovecot restart Stopping Dovecot Imap: [ OK ] Starting Dovecot Imap: [ OK ]
$ telnet imapserver imap Trying 1.1.1.1... Connected to imapserver (1.1.1.1). Escape character is '^]'. permitted.
- OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE AUTH=PLAIN] Dovecot ready. 1 LOGIN imapuser imapuserpassword 1 OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTOR E QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS] Logged in 2 select INBOX
- FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
- OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags
- 2 EXISTS
- 0 RECENT
- OK [UNSEEN 1] First unseen.
- OK [UIDVALIDITY 1356130761] UIDs valid
- OK [UIDNEXT 8] Predicted next UID
- OK [HIGHESTMODSEQ 1] Highest 2 OK [READ-WRITE] Select completed. 3 FETCH 1 BODY[]
- 1 FETCH (FLAGS (\Seen) BODY[] {39306}
..... some brief message output .....
Connection closed by foreign host.
And then I get an empty core file:
[root@imapserver]# pwd /mnt/mail/imapuser [root@imapserver]# ls -lh core* -rw------- 1 imapuser imapuser 0 Dec 30 00:56 core.7319
On Sat, Dec 29, 2012 at 12:18 PM, Jim Lawson jtl+dovecot@uvm.edu wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Eric,
On 12/25/12 9:26 PM, Eric wrote:
Happy holidays! I am experiencing an issue when trying to check my mail using IMAP. with Dovecot I have tried checking my mail using a full GUI client (Thunderbird) and telnet. Both times I get disconnected before all of my messages can be downloaded and I see an error in my mail log. Here are the details:
[root@cust19-1-prod-domain userqa]# dovecot --version 2.0.9
There have been a lot of fixes since that version; can you confirm that this problem is not in 2.0.19 (or better yet, 2.1.12?)
i enabled core dumps:
echo 'DAEMON_COREFILE_LIMIT="unlimited"' >> /etc/sysconfig/dovecot
Does that work? The point is to set "ulimit -c unlimited". I don't know what package you're using, but Dovecot doesn't ship with an init script (at least, 2.0.9 didn't.) The only thing I know of is at http://wiki.dovecot.org/DovecotInit, and that doesn't use /etc/sysconfig at all.
Now I see this in /var/log/maillog:
2012-12-25T17:53:47-08:00 cust19-1-prod-domain dovecot: master: Error: service(imap): child 11265 killed with signal 11 (core dumped)
core dumps are being written here, but they're empty:
If you're still getting core dumps with 2.0.19, check your setting of "ulimit -c". It should be "unlimited" for this case. You may need to modify /etc/init.d/dovecot. My guess is that your /etc/sysconfig/dovecot modification is having no effect.
Jim -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) Comment: Using GnuPG with undefined - http://www.enigmail.net/
iQIcBAEBAgAGBQJQ31ASAAoJELUeD3oQ5ZpZkfIQAKEoVPO0Cldfec12WC/dGGoZ gdkZ10boxc+OoWP3Yhx4reWgIrvodaHaz7jxAhXGwasILXWRTP4vPxWCd77PjNNB JXGQpimCJZaFtcQ6PKONqqz7jqZ6zj07ZzKJeZXrSSxzmH7zrgAveA0xi3k+OGpr qCv60j4qlHEyw3I2FBDzO1GokpCbWS0Z3FDBUM1Zf5yFgRNSvt3FK9FQXejRwYnO vsNiMINO/Z5x8FLp0CfqbsQDnInAPPFV73UnGPVkFOpnswCytRX6ILNm2e9jIs9s G2qSalVOIATbgxnL1DkjLpex+gslJBrBqQy2lIeUv0GMxn/vMCw7dmxPAW+ankup qd1izm6iKUXEhnz7CKgh3FX3kp/W0ijvBKwDRqwzPCKkOTdLKkjygKzfxtfZE6Ay NFyeN21zorb+EZUmDtoQNxDT7iLKNf9dK0dZDY4xVU7KnyFbheppK0CUVsCUq1F0 oYggVUJXtT2rshVUocPjYFF56y+Hgi8a0rAWfi5j+qmD1eqTjKJcRbIdu9AhUkW+ OD4tqgMNRAW5Ry4HDdWVCaPnyzILL+p2g/ujKN9MV5m82DFOUWy+jiB5F5iXXc/r H2ywrPH/ko0WGnTi7inPQJQ3ecu0seJ+wkwFPYNAmbXSV1Fp0NReJA5Cn6m/PKEC 1OxYVGRIJdLlF99zxDMw =jurE -----END PGP SIGNATURE-----