dovecot - May 2007 - No authentication sockets found

Thunderbird (2.0) is all of a sudden checking mail server capabilities 
and keep posting a popup saying:
"Mail Server imap.bard.edu is not an IMAP4 mail server".  To the best
of
my knowledge, neither Tbird nor DC have been updated, though the DC imap 
host was rebooted today 3 hours ago.  Any info on what this is about?  
DC is currently serving out of a special port and in evaluation 
list....I can't imagine that this message would please the user 
community!   Killing and restarting dovecot appears to have at least 
temporarily stopped this behavior.

Also and perhaps related, I am seeing a syslog message:
imap-login: No authentication sockets found
child xxxxxx (login) returned error 89

using SSL encrypted IMAP service

Background: DC 1.0, invoked from /etc/rc.local during boot.  After 
stopping and restarting DC, things seem to work again. As per an old 
problem, I checked /var/run/dovecot, but it was empty with plenty of 
space.  FWIW, the owner/group for login dir (/var/run/dovecot) is 
dovecot:dovecot, perm 755, while /var/run/dovecot/login is root:dovecot, 
750.
Host is running AIXV5.3 TL5 SP6 (latest level), DC is compiled with 
IBM's AIX for C, V6.0
dovecot -n output
> # /usr/local/etc/dovecot.conf
> listen: *:10143
> ssl_listen: *:10943
> disable_plaintext_auth: no
> verbose_ssl: yes
> login_dir: /var/run/dovecot/login
> login_executable: /usr/local/libexec/dovecot/imap-login
> verbose_proctitle: yes
> first_valid_uid: 200
> mail_location: mbox:~/mail:INBOX=/var/spool/mail/%u:INDEX=/var/dcndx/%u
> mail_debug: yes
> mbox_dirty_syncs: no
> mbox_lazy_writes: no
> auth default:
>   verbose: yes
>   debug: yes
>   passdb:
>     driver: pam
>   userdb:
>     driver: passwd
Do I need to set an O/S or SSL max for authentication sockets?  If so, 
any info would be appreciated

Thanks!

-- 
===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

On Wed, 2007-05-09 at 10:59 -0400, Stewart Dean wrote:
> DC imap host was rebooted today 3 hours ago.  Any info on what this is
about?
..
> imap-login: No authentication sockets found
..
> Background: DC 1.0, invoked from /etc/rc.local during boot.  After 
> stopping and restarting DC, things seem to work again. As per an old 
> problem, I checked /var/run/dovecot, but it was empty with plenty of 
> space.  FWIW, the owner/group for login dir (/var/run/dovecot) is 
> dovecot:dovecot, perm 755, while /var/run/dovecot/login is root:dovecot, 
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..

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20070511/7ea30050/attachment.bin>

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.
Best regards


2007/5/11, Timo Sirainen <tss at iki.fi>:
>
> On Wed, 2007-05-09 at 10:59 -0400, Stewart Dean wrote:
> > DC imap host was rebooted today 3 hours ago.  Any info on what this is
> about?
> ..
> > imap-login: No authentication sockets found
> ..
> > Background: DC 1.0, invoked from /etc/rc.local during boot.  After
> > stopping and restarting DC, things seem to work again. As per an old
> > problem, I checked /var/run/dovecot, but it was empty with plenty of
> > space.  FWIW, the owner/group for login dir (/var/run/dovecot) is
> > dovecot:dovecot, perm 755, while /var/run/dovecot/login is
root:dovecot,
>
> 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..
>
>
>

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