Hi stewart i can see these errors in my log if i try to start dovecot while dovecot is working. It start to gives error after some time. I think it may be corrected. Because if someone forget dovecot is working and give command /usr/local/sbin/dovecot it cannot contact the authentication socket. My dovecot is on AIX 5.3 i am not using ssl. Maybe it can give you some idea about your authenticaiton socket problem. It is not about MTA. i am sorry for my previous message. I hope you can find out your solution.
May 21 11:59:36 mailtest mail:info dovecot: auth(default): master out: USER 7 AB105560 home=/mail/vmail/AB105560/ quota=maildir:storage=9000000 uid=5000 gid=5000 May 21 11:59:36 mailtest mail:info dovecot: imap-login: Login: user=<AB105560>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, secured May 21 11:59:36 mailtest mail:info dovecot: IMAP,user=<AB105560>,lip= 127.0.0.1 rip=127.0.0.1 method= : Loading modules from directory: /usr/local/lib/dovecot/imap May 21 11:59:36 mailtest mail:info dovecot: IMAP,user=<AB105560>,lip= 127.0.0.1 rip=127.0.0.1 method= : Module loaded: /usr/local/lib/dovecot/imap/lib10_quota_plugin.so May 21 11:59:36 mailtest mail:info dovecot: IMAP,user=<AB105560>,lip= 127.0.0.1 rip=127.0.0.1 method= : Module loaded: /usr/local/lib/dovecot/imap/lib11_imap_quota_plugin.so May 21 11:59:36 mailtest mail:info dovecot: IMAP,user=<AB105560>,lip= 127.0.0.1 rip=127.0.0.1 method= : Effective uid=5000, gid=5000, home=/mail/vmail/AB105560/ May 21 11:59:36 mailtest mail:info dovecot: IMAP,user=<AB105560>,lip= 127.0.0.1 rip=127.0.0.1 method= : Namespace: type=private, prefix=, sep=., inbox=yes, hidden=no, subscriptions=no May 21 11:59:36 mailtest mail:info dovecot: IMAP,user=<AB105560>,lip= 127.0.0.1 rip=127.0.0.1 method= : maildir: data=/mail/vmail/AB105560/ May 21 11:59:36 mailtest mail:info dovecot: IMAP,user=<AB105560>,lip= 127.0.0.1 rip=127.0.0.1 method= : maildir: root=/mail/vmail/AB105560, index=/mail/vmail/AB105560, control=, inbox= May 21 11:59:36 mailtest mail:info dovecot: IMAP,user=<AB105560>,lip= 127.0.0.1 rip=127.0.0.1 method= : Disconnected: Logged out May 21 11:59:39 mailtest mail:err|error dovecot: imap-login: No authentication sockets found May 21 11:59:39 mailtest mail:err|error dovecot: child 1151150 (login) returned error 89 May 21 11:59:40 mailtest mail:err|error dovecot: imap-login: No authentication sockets found May 21 11:59:40 mailtest mail:err|error dovecot: child 266360 (login) returned error 89
2007/5/18, Stewart Dean sdean@bard.edu:
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
Back on 5/9, I made a post by this subject http://dovecot.org/list/dovecot/2007-May/022482.html Timo replied: postfix
- 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).
(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:
May 14 15:34:09 mercury mail:info dovecot: Dovecot v1.0.0 starting up
- 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@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
- 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
- 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: problem
- This machine had been booted 5 days before so it's not a boot related
- 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
- /var/run is local to the DC host and is not exported
- 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:
- 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.
- 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@bard.edu voice: 845-758-7475, fax: 845-758-7035