[SOLVED] Can't receive external mails after Debian safe-upgrade Debian GNU/Linux 6.0.8 (squeeze) ISPConfig 3.0.5.3 After this: # aptitude update # aptitude -s safe-upgrade # aptitude safe-upgrade I can send mails to any server, I can receive internal mails (from my server), but I can't receive external mails (from gmail, hotmail,...). I get these errors: Mar 3 05:19:08 servidor authdaemond: failed to connect to mysql server (server=localhost, userid=ispconfig): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) Mar 3 05:19:08 servidor pop3d: authentication error: Input/output error But I can connect to mysql dbispconfig database with ispconfig user, my /etc/hosts is OK, etc. (I read and tried all the recipes located in this forum). I written the safe-upgraded packages and restored my OpenVZ VM. The safe-upgraded packages were: apache2 (2.2.16-6+squeeze11 => 2.2.16-6+squeeze12) apache2.2-bin (2.2.16-6+squeeze11 => 2.2.16-6+squeeze12) apache2.2-common (2.2.16-6+squeeze11 => 2.2.16-6+squeeze12) apache2-doc (2.2.16-6+squeeze11 => 2.2.16-6+squeeze12) apache2-mpm-prefork (2.2.16-6+squeeze11 => 2.2.16-6+squeeze12) apache2-suexec (2.2.16-6+squeeze11 => 2.2.16-6+squeeze12) apache2-utils (2.2.16-6+squeeze11 => 2.2.16-6+squeeze12) base-files (6.0squeeze8 => 6.0squeeze9) file (5.04-5+squeeze2 => 5.04-5+squeeze3) libapache2-mod-php5 (5.3.3-7+squeeze18 => 5.3.3-7+squeeze19) libmagic1 (5.04-5+squeeze2 => 5.04-5+squeeze3) libmagic-dev (5.04-5+squeeze2 => 5.04-5+squeeze3) libpq5 (8.4.17-0squeeze1 => 8.4.20-0squeeze1) libpq-dev (8.4.17-0squeeze1 => 8.4.20-0squeeze1) librsvg2-2 (2.26.3-1 => 2.26.3-1+deb6u2) php5 (5.3.3-7+squeeze18 => 5.3.3-7+squeeze19) php5-cgi (5.3.3-7+squeeze18 => 5.3.3-7+squeeze19) php5-cli (5.3.3-7+squeeze18 => 5.3.3-7+squeeze19) php5-common (5.3.3-7+squeeze18 => 5.3.3-7+squeeze19) php5-curl (5.3.3-7+squeeze18 => 5.3.3-7+squeeze19) php5-dev (5.3.3-7+squeeze18 => 5.3.3-7+squeeze19) php5-gd (5.3.3-7+squeeze18 => 5.3.3-7+squeeze19) php5-imap (5.3.3-7+squeeze18 => 5.3.3-7+squeeze19) php5-intl (5.3.3-7+squeeze18 => 5.3.3-7+squeeze19) php5-ldap (5.3.3-7+squeeze18 => 5.3.3-7+squeeze19) php5-mcrypt (5.3.3-7+squeeze18 => 5.3.3-7+squeeze19) php5-mysql (5.3.3-7+squeeze18 => 5.3.3-7+squeeze19) php5-tidy (5.3.3-7+squeeze18 => 5.3.3-7+squeeze19) php5-xmlrpc (5.3.3-7+squeeze18 => 5.3.3-7+squeeze19) php-pear (5.3.3-7+squeeze18 => 5.3.3-7+squeeze19) tzdata (2013d-0squeeze1 => 2013i-0squeeze1) Please, are there any suspected of being the cause of this error? Thanks! Manuel
Hi, as far as I can see, none of the packages that you listed above is directly involved in the pop3 authentication process. Maybe you reached a openvz limit which has caused the aborted mysql connections. Please check with: cat /proc/user_beancounters in the vm. Did you check if the mysql socket was there with: ls -la /var/run/mysqld/mysqld.sock The ispconfig interface connects to mysql by tcp on localhots and not through the socket, so it can be that the socker connection failed while mysqlw as listening on localhost. Did you try to restart the vm after the update?
It was also strange to me (hence my question). I'll try it tonight, updating packages individually or in groups. I think not: night is when we have less traffic. Thanks, I will check it this night. Currently is: Code: # cat /proc/user_beancounters Version: 2.5 uid resource held maxheld barrier limit failcnt 101: kmemsize 3957728844 4012994560 11712593920 12884901888 0 lockedpages 0 9 3145728 3145728 0 privvmpages 1120756 1686983 9223372036854775807 9223372036854775807 0 shmpages 1082 1738 9223372036854775807 9223372036854775807 0 dummy 0 0 0 0 0 numproc 189 279 1024 1024 0 physpages 2385575 2442588 0 6291456 0 vmguarpages 0 0 0 9223372036854775807 0 oomguarpages 834723 867424 0 9223372036854775807 0 numtcpsock 89 169 9223372036854775807 9223372036854775807 0 numflock 84 114 9223372036854775807 9223372036854775807 0 numpty 1 24 255 255 0 numsiginfo 1 42 1024 1024 0 tcpsndbuf 1878296 3720880 9223372036854775807 9223372036854775807 0 tcprcvbuf 1458176 3019608 9223372036854775807 9223372036854775807 0 othersockbuf 354448 2044712 9223372036854775807 9223372036854775807 0 dgramrcvbuf 0 176800 9223372036854775807 9223372036854775807 0 numothersock 277 369 9223372036854775807 9223372036854775807 0 dcachesize 3912209252 3912270436 5856296960 6442450944 0 numfile 4048 5680 9223372036854775807 9223372036854775807 0 dummy 0 0 0 0 0 dummy 0 0 0 0 0 dummy 0 0 0 0 0 numiptent 1080 1105 9223372036854775807 9223372036854775807 0 Yes, I checked this: mysqld.sock was there. Yes, I restarted several times. I will continue this night. Thanks! Manuel
The mysql login etails for courier are in the courier authdaemonrc file in /etc/courier/ just in case that you want to check and play around with them if the isue occurs agan after update.
Thanks, Till, I have no played with authdaemonrc after update, only with authmysqlrc (no changes after safe-upgrade, and the change of MYSQL_PORT from 0 to 3306 don't solved the problem). I will play with authdaemonrc this night if necessary. Currently, the non commented content of these files is: # vi /etc/courier/authdaemonrc authmodulelist="authmysql" authmodulelistorig="authuserdb authpam authpgsql authldap authmysql authcustom authpipe" daemons=5 authdaemonvar=/var/run/courier/authdaemon DEBUG_LOGIN=0 DEFAULTOPTIONS="" LOGGEROPTS="" # vi /etc/courier/authmysqlrc MYSQL_SERVER localhost MYSQL_USERNAME ispconfig MYSQL_PASSWORD *** MYSQL_PORT 0 MYSQL_DATABASE dbispconfig MYSQL_USER_TABLE mail_user MYSQL_CRYPT_PWFIELD password #MYSQL_CLEAR_PWFIELD password MYSQL_UID_FIELD uid MYSQL_GID_FIELD gid MYSQL_LOGIN_FIELD login MYSQL_HOME_FIELD homedir MYSQL_MAILDIR_FIELD maildir MYSQL_QUOTA_FIELD quota MYSQL_AUXOPTIONS_FIELD concat('disableimap=',disableimap,',disablepop3=',disablepop3) Regards, Manuel
Thats the standard config, so it normally should work. You can try to set: DEBUG_LOGIN=1 to get a more detailed log output in the mail.log file.
Problem located and solved! In June 2011 I installed Postgrey in this OpenVZ VM, following the HOWTO: Spam control for POSTFIX published by the user crypted (many thanks!). In order to get Postgrey working with Postfix, I added check_policy_service inet:127.0.0.1:10023 to smtpd_recipient_restrictions in /etc/postfix/main.cf. Yesterday, after safe-upgrade Debian Squeeze, check_policy_service inet:127.0.0.1:10023 prevented the entry of external mails: # tail -f /var/log/mail.log postfix/smtpd: connect from mail-qc0-f170.google.com postfix/smtpd: warning: connect to 127.0.0.1:10023: Connection refused postfix/smtpd: warning: problem talking to server 127.0.0.1:10023: Connection refused postfix/smtpd: warning: connect to 127.0.0.1:10023: Connection refused postfix/smtpd: warning: problem talking to server 127.0.0.1:10023: Connection refused postfix/smtpd: NOQUEUE: reject: RCPT from mail-qc0-f170.google.com: 451 4.3.5 Server configuration problem; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<mail-qc0-f170.google.com> postfix/smtpd: disconnect from mail-qc0-f170.google.com Solution: add 127.0.0.1: to POSTGREY_OPTS in /etc/default/postgrey: # vi /etc/default/postgrey ... POSTGREY_OPTS="--inet=127.0.0.1:10023" ... And restart Postgrey and Postfix. Hope this helps someone else. Thanks for your help and cordial greetings, Manuel
