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=<[EMAIL PROTECTED]>, 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
[EMAIL PROTECTED] voice: 845-758-7475, fax: 845-758-7035
