[Dovecot] No authentication sockets found

Stewart Dean sdean at bard.edu
Fri May 18 22:23:11 EEST 2007


Back on 5/9, I made a post by this subject
http://dovecot.org/list/dovecot/2007-May/022482.html
Timo replied:
> The error message means that /var/run/dovecot/login directory or its
> contents was deleted while Dovecot was running. I'd guess that you start
> Dovecot too early and after startup another script goes and deletes the
> entire /var/run/ directory. Or maybe that's done in background. Or
> something..
and funkypunkydrunky reported:
> I have lived the same problem in my system. But not evrytime sometimes it
> only happens when i restart dovecot while mta is working. I think postfix
> (my mta) cannot connect the new authentication socket. If i need the
> restarting dovecot, i restart postfix  too. It happens only for the above
> situation.
This happened again under these circumstances:
1) The machine had been up for 5 days.  Having made some changes 
(largely de-verbosifying the dovecot.conf file), I killed the master 
dovecot process and restarted it (this before I was informed I could 
just do a kill -1 to effect the same result with less trouble).
> May 14 15:34:09 mercury mail:info dovecot: Dovecot v1.0.0 starting up
>
>   
2) Using TBird a an imap client, I got back on
> May 14 15:24:48 mercury mail:info dovecot: auth(default): client out: CONT      1
> May 14 15:24:48 mercury mail:info dovecot: auth(default): client in: CONT       1       AHNkZWFuAEFsYW1hcjJi
> May 14 15:24:48 mercury mail:info dovecot: auth(default): pam(sdean,10.20.10.75): lookup service=dovecot
> May 14 15:24:49 mercury mail:info sendmail-SndRcv[2220248]: l4EJOief2949348: to=<cooper at bard.edu>, delay=00:00:01, xdelay=00:00:01, mailer=local, pri=36928, dsn=2.0.0, stat=Sent
> May 14 15:24:49 mercury mail:info dovecot: auth(default): client out: OK        1       user=sdean
> May 14 15:24:49 mercury mail:info dovecot: auth(default): master in: REQUEST    6       909440  1
> May 14 15:24:49 mercury mail:info dovecot: auth(default): passwd(sdean,10.20.10.75): lookup
> May 14 15:24:49 mercury mail:info dovecot: auth(default): master out: USER      6       sdean   system_user=sdean       uid=202 gid=200 home=/home/hcrc/sdean
> May 14 15:24:49 mercury mail:info dovecot: imap-login: Login: user=<sdean>, method=PLAIN, rip=10.20.10.75, lip=192.246.229.21, TLS
> May 14 15:24:49 mercury mail:info dovecot: IMAP(sdean): Effective uid=202, gid=200, home=/home/hcrc/sdean
> May 14 15:24:49 mercury mail:info dovecot: IMAP(sdean): mbox: data=/home/hcrc/sdean/mail:INBOX=/var/spool/mail/sdean:INDEX=/var/dcndx/sdean
> May 14 15:24:49 mercury mail:info dovecot: IMAP(sdean): mbox: root=/home/hcrc/sdean/mail, index=/var/dcndx/sdean, inbox=/var/spool/mail/sdean
>
>
>   
3) 15 seconds after that, I started seeing a slew of these error 
messages, every 15 seconds or so:
> May 14 15:25:03 mercury mail:info imapd[2052334]: Logout user=ot119 host=[10.20.10.10]
> May 14 15:25:04 mercury mail:err|error dovecot: imap-login: No authentication sockets found
> May 14 15:25:04 mercury mail:err|error dovecot: child 835676 (login) returned error 89
>   
4) Since this is the production server, I kill the master dovecot 
instance and reinvoke dovecot in the foreground.  I haven't seen the 
problem again since....but twice is problematic with just 3 people using DC.

Now.  My thoughts about what has been suggested so far, first by Timo:
1) This machine had been booted 5 days before so it's not a boot related 
problem
2) I'd find it hard to believe that something is nuking the contents of 
/var/run because:
    a) The directory doesn't exist by default in AIX; I created it for 
the DC install
    b) I have cron jobs that do cleanup with /var/log, /var/log/arc and 
/var/spool/mqueue, but nothing that does anything to /var/run
3) /var/run is local to the DC host and is not exported
4) funkypunkydrunky's comments about interaction with the MTA (sendmail 
in my case) seem unlikely, since it doesn't use SSL...or the same ports

My questions:
1) What is happening?  This is OpenSSL related, yes?
2a) Will this affect my production UWIMAP (which also supports/utilizes 
SSL)?  If it doesn't, I can take my time debugging it (given that there 
are only 3 IT guys using DC currently), instead of frantically shutting 
it up by rebooting ASAP.  I /think/ previously established DC 
connections continued to work
2b) How will this affect other imaps DC nex and pre-extant connections?  
I'm thinking of putting the whole IT dept on DC, but it'd be good to 
know how flaky things would get if/when this happens again.
3) What can I do to debug it, given that it happens infrequently and of 
no known causation?  What should I check and look for afterwards? I 
guess I could put a cronjob that checks that /var/run/dovecot/login/ 
default= and ssl-parameters.dat exists periodically

====
Stewart Dean, Unix System Admin, Henderson Computer Resources

Center of Bard College, Annandale-on-Hudson, New York  12504  
sdean at bard.edu  voice: 845-758-7475, fax: 845-758-7035



More information about the dovecot mailing list