Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

...this was a hard one to describe in a title. This description should highlight the problem.

Context

  • I was following the Workaround.org tutorial to install a postfix, dovecot (plus some additional plugins) stack.
  • Running on a Ubuntu 12.04 machine (VM with Vagrant/Chef)
  • Dovecot v2.0.19
  • Postfix v2.9.6

Conf. Files

10-master

....
service auth {    
unix_listener auth-userdb {
  mode = 0644
  user = vmail
  group = vmail
}
...

Edit - additional config info(some overlap)

service auth {
# auth_socket_path points to this userdb socket by default. It's typically
# used by dovecot-lda, doveadm, possibly imap process, etc. Its default
# permissions make it readable only by root, but you may need to relax these
# permissions. Users that have access to this socket are able to get a list
# of all usernames and get results of everyone's userdb lookups.
unix_listener auth-userdb {
  mode = 0644
  user = vmail
  group = vmail
}

# Postfix smtp-auth
unix_listener /var/spool/postfix/private/auth {
  mode = 0660
  user = postfix
  group = postfix
}

# Auth process is run as this user.
#user = $default_internal_user
user = dovecot
}

auth-sql

userdb {
  driver = static
  args = uid=vmail gid=vmail home=/var/vmail/%d/%n allow_all_users=yes
}

ls -la /var/run/dovecot/auth-userdb

srw-r--r-- 1 vmail vmail 0 Jun 20 13:04 /var/run/dovecot/auth-userdb

Postfix master.cf

dovecot    unix  -      n       n       -       -       pipe
   flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/dovecot-lda -d ${recipient}

Problem

I have followed the tutorial pretty closely, changing only some minor things. I arrived at the "Testing mail delivery" and ran echo test | mail test@chefdovecot.com

The mail didn't arrive since find /var/vmail didn't show anything.

In the server syslog the following errors are present:

postfix/pickup[16842]: 019023A06AB: uid=1000 from=<vagrant>
postfix/cleanup[19542]: 019023A06AB: message-id=   <20130620140358.019023A06AB@mail-server-berkshelf>
postfix/qmgr[16843]: 019023A06AB: from=<vagrant@mail-server-berkshelf.localdomain>, size=382, nrcpt=1 (queue active)
dovecot: lda: Debug: Loading modules from directory: /usr/lib/dovecot/modules
dovecot: lda: Debug: Module loaded: /usr/lib/dovecot/modules/lib90_sieve_plugin.so
dovecot: lda: Error: userdb lookup: connect(/var/run/dovecot/auth-userdb) failed: Connection refused
dovecot: lda: Fatal: Internal error occurred. Refer to server log for more information.
postfix/pipe[19545]: 019023A06AB: to=<test@chefdovecot.com>, relay=dovecot, delay=1.2, delays=0.04/0.01/0/1.1, dsn=4.3.0, status=deferred (temporary failure)

The "connection refused" error should be the error I'm attacking, right? I've searched in a lot of places to understand what is going on here, but haven't come across anything helpful.

Can anyone provide any leads or insights? A solution would be great, but I'm happy to accept some new ideas to try out.

share|improve this question
    
I've always used postfix or dovecot as the user for the authdb file.. –  NickW Jun 21 '13 at 8:37
    
Could a "Connection refused" error have to do with who I'm running the processes as? I would expect that to be a file permission error or such. From the error message, it seems that a connection is actually trying to be made, but gets rejected. –  Adam Jun 21 '13 at 8:42
    
Yeah, it could be something "underneath" the file presented, if you're using SQL, can you see any connection being attempted? It says to look in the dovecot log for further details though, is there one? –  NickW Jun 21 '13 at 8:50
    
I am using SQL. The request via auth-userdb (which I assume is to query the password and authenticate), never makes it to MySQL. Postfix queries for the domain, user and destination all get through (this is of course before the auth-userdb error). I changed the permissions to 777 to eliminate to possibility of simple file permissions, and that didn't help. Any thoughts on how to uncover some of the "underneath" workings? Also, dovecot is logging to syslog, the above snippet are a mix between dovecot and postfix log msgs. –  Adam Jun 21 '13 at 9:11
    
This is the LDA part, how have you configured that in your master.cf? –  NickW Jun 21 '13 at 9:20

1 Answer 1

up vote 1 down vote accepted
+50

The connection refused error is indeed the problem. Connection refused on unix sockets is not terribly intuitive, but it indicates that there is nothing listening on the socket (typically, the process is dead, or the file given as the address wasn't a socket at all). This should never be a permissions issue, unless dovecot is unable to open the socket for listening due to permissions.

Try stopping dovecot and postfix, removing the socket file at /var/run/dovecot/auth-userdb, and starting postfix and dovecot again (ensuring the user dovecot is running as has permissions on /var/run/dovecot). Usually this will fix this type of issue.

Netstat will also display unix domain sockets. Check its output (use netstat -nvlap | less and search for the path or for dovecot) to ensure dovecot is listening.

share|improve this answer
    
When you say "removing the socket file", you don't mean rm -f right? I suppose you mean from the config file? Could you clarify that part a bit? –  Adam Jun 24 '13 at 8:31
    
I absolutely mean to say delete the socket file using rm. When you open a new listening socket, the file will be created if it doesn't exist; removing it, starting the process that listens on it (so it gets created), and starting the process that connects to it should ensure consistency. –  Falcon Momot Jun 24 '13 at 8:45
    
Worked great. Thanks for your input, I didn't have the knowledge to try something like that. –  Adam Jun 24 '13 at 9:17

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.