[Dovecot] May 21 09:13:14 mail dovecot: imap-login: No authentication sockets found
I started getting this message this morning: May 21 09:13:14 mail
dovecot: imap-login: No authentication sockets found
Ive been runing dovecot on a fc6 dell poweredge 2950 for about 4 weeks
now with no issues. Im authenticating against openldap 2.3.27. It
appears ok. I restarted ldap, and dovecot, and everything looked fine
for a few minutes, then this started again. I have around 720 users.
Is there a setting in the dovecot.conf that I can use to fix this? Or
is the problem elsewhere?
-- Dwayne Hottinger Network Administrator Harrisonburg City Public Schools
On Mon, 2007-05-21 at 09:21 -0400, dhottinger@harrisonburg.k12.va.us wrote:
What Dovecot version? The error message means that Dovecot's login_dir (/var/run/dovecot/login) was cleaned. A few other people have been having this problem, but I haven't yet found out any bugs in Dovecot that would cause it. Except before v1.0.rc29 if you tried to start Dovecot while it was already running it would do this.
On Mon, 2007-05-21 at 22:31 +0300, Timo Sirainen wrote:
Actually I was wrong. I fixed it for "dovecot -n" and "dovecot -a", but actually trying to start Dovecot while it's already running will wipe out the login directory. I'll go fix this for v1.0.1.
I went back and looked, and you have sent a few messages to the list, but not once have you mentioned what version of dovecot, or provided dovecot -n output...
--
Best regards,
Charles
dhottinger@harrisonburg.k12.va.us wrote:
As Timo mentioned, it sounds like the auth socket is being deleted because it's in a place that the 'tmpwatch' tool will clean out; the default on FC6 is anything more than 720hrs old (30 days), which fits right in to your 4-week observation.
Compare the location of your sockets/cache (dovecot -n) with the list of directories cleaned by tmpwatch (look in /etc/cron.daily/tmpwatch) and make sure the two aren't stepping on each other's toes.
-te
-- Troy Engel | Systems Engineer Fluid, Inc | http://www.fluid.com
Quoting Troy Engel <tengel@fluid.com>:
tmpwatch:
/usr/sbin/tmpwatch -x /tmp/.X11-unix -x /tmp/.XIM-unix -x /tmp/.font-unix
-x /tmp/.ICE-unix -x /tmp/.Test-unix 240 /tmp
/usr/sbin/tmpwatch 720 /var/tmp
for d in /var/{cache/man,catman}/{cat?,X11R6/cat?,local/cat?}; do
if [ -d "$d" ]; then
/usr/sbin/tmpwatch -f 720 "$d"
fi
done
dovecot -n [root@mail ~]# dovecot -n
/etc/dovecot.conf
login_dir: /var/run/dovecot/login login_executable(default): /usr/libexec/dovecot/imap-login login_executable(imap): /usr/libexec/dovecot/imap-login login_executable(pop3): /usr/libexec/dovecot/pop3-login mail_location: mbox:~/:INBOX=/var/mail/%u mail_debug: yes mail_executable(default): /usr/libexec/dovecot/imap mail_executable(imap): /usr/libexec/dovecot/imap mail_executable(pop3): /usr/libexec/dovecot/pop3 mail_plugin_dir(default): /usr/lib/dovecot/imap mail_plugin_dir(imap): /usr/lib/dovecot/imap mail_plugin_dir(pop3): /usr/lib/dovecot/pop3 auth default: passdb: driver: pam userdb: driver: passwd I dont see anything about the auth socket. Been a long day though.
ddh
-- Dwayne Hottinger Network Administrator Harrisonburg City Public Schools
dhottinger@harrisonburg.k12.va.us wrote:
Just FYI, you are not authenticating [dovecot] against OpenLDAP; you're authenticating using PAM, and it's PAM who is doing the LDAP lookups via nss_ldap. (http://wiki.dovecot.org/AuthDatabase/Passwd)
Did you have all the other 'old' (30d+) files in /var/run/dovecot/ before having restarted the daemon(s)? Any chance you saved a ls -l of that dir somehow? One thing to check is if the socket alone disappeared, or if others (the PID file, for example) were also gone. Since they'd typically have the same datetime stamp, it would provide a clue...
-te
-- Troy Engel | Systems Engineer Fluid, Inc | http://www.fluid.com
dhottinger@harrisonburg.k12.va.us wrote:
Yes I knew I was authenticating against pam. Didnt do an ls -l of the /var/run/dovecot. Wouldnt a restart of dovecot fix that though?
Correct, the concept was *before* you restarted the daemon, to try and capture as much info first. It's hard when you're under the gun and need to restore services, but if it happens again I'd suggest scraping the system for clues for a few minutes. (ls -laR important dirs like /var/run/dovecot, ps -ef, maybe some lsof and lslk action, etc.)
-te
-- Troy Engel | Systems Engineer Fluid, Inc | http://www.fluid.com
On Mon, 2007-05-21 at 14:37 -0700, Troy Engel wrote:
Does some system really do this? I'd think it would break other software as well. I see at least that I have /var/run/mysqld/mysqld.sock which hasn't been updated since it was started. And then there are a lot of .pid files as well.
Timo Sirainen wrote:
Only *certain* directories (ddh pasted the output of a default file). By default the /var/run/dovecot should be left alone, but it never hurts to have people check their system...
-te
-- Troy Engel | Systems Engineer Fluid, Inc | http://www.fluid.com
participants (5)
-
Charles Marcus
-
dhottinger＠harrisonburg.k12.va.us
-
funkypunky drunky
-
Timo Sirainen
-
Troy Engel