Mark Hedges wrote: > > On Fri, 27 Feb 2009, Timo Sirainen wrote: >> OK, so core dumps are enabled, but for some reason they >> don't get written. There are really only two possibilities >> then: >> >> a) You don't really have mail_drop_priv_before_exec=yes. >> You could verify this with dovecot -n. > > [r...@anubis etc]# /usr/local/sbin/dovecot -n | grep drop > mail_drop_priv_before_exec: yes > >> b) Kernel doesn't want to write the core to /tmp/core or >> before changing that it didn't want to write it to user's >> home directory. > > [r...@anubis etc]# grep -i core > /boot/config-2.6.18-92.1.22.el5 > CONFIG_ELF_CORE=y > # Core Netfilter Configuration > CONFIG_MLX4_CORE=m > CONFIG_SERIAL_CORE=y > CONFIG_SERIAL_CORE_CONSOLE=y > # CONFIG_I2C_OCORES is not set > # CONFIG_I2C_DEBUG_CORE is not set > CONFIG_PROC_KCORE=y > CONFIG_PROC_VMCORE=y > > Is that informative? I would not be surprised if the kernel > is buggy. It also indefinitely holds onto network > connections in CLOSE_WAIT state, never times them out, and > after some list research it seems there's no option to > control that, could be wrong, but I gave up. >
Totally unrelated to your Dovecot issues, but are you using an Intel card with that kernel? Specifically the e1000 driver is buggy enough in that version that I gave up and use at least kernel 2.6.20.3 with e1000 cards. I wouldn't be surprised if there were other network related issues. ~Seth