Back on 5/9, I made a post by this subject http://dovecot.org/list/dovecot/2007-May/022482.html Timo replied:
- 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).
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:
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