Hi, as the title says every few weeks saslauthd appears to stop working causing an SASL LOGIN authentication failed: authentication failure in the log whenever an SMTP attempt is made. Jun 6 07:11:07 srv5 postfix/smtpd[27251]: warning: unknown[212.15.178.94]: SASL PLAIN authentication failed: authentication failure Jun 6 07:11:19 srv5 postfix/smtpd[27251]: warning: SASL authentication failure: Password verification failed Jun 6 07:11:19 srv5 postfix/smtpd[27251]: warning: unknown[212.15.178.94]: SASL PLAIN authentication failed: authentication failure Jun 6 07:11:19 srv5 postfix/smtpd[27251]: warning: SASL authentication failure: Password verification failed Jun 6 07:11:19 srv5 postfix/smtpd[27251]: warning: unknown[212.15.178.94]: SASL PLAIN authentication failed: authentication failure Jun 6 07:11:38 srv5 postfix/smtpd[27251]: warning: SASL authentication failure: Password verification failed Jun 6 07:11:38 srv5 postfix/smtpd[27251]: warning: unknown[212.15.178.94]: SASL PLAIN authentication failed: authentication failure Jun 6 07:11:43 srv5 postfix/smtpd[27251]: warning: SASL authentication failure: Password verification failed As soon as I restart saslauthd everything starts working properly again. Checking ps aux when things have stopped working still shows the standard 5 processes. root@srv5:~# ps aux | grep 'saslauthd' root 24693 0.0 0.4 151836 76560 ? Ss May21 0:03 /usr/sbin/saslauthd -a pam -c -m /var/spool/postfix/var/run/saslauthd -r -n 5 root 24695 0.0 0.4 151844 76540 ? S May21 0:03 /usr/sbin/saslauthd -a pam -c -m /var/spool/postfix/var/run/saslauthd -r -n 5 root 24696 0.0 0.4 151948 76536 ? S May21 0:03 /usr/sbin/saslauthd -a pam -c -m /var/spool/postfix/var/run/saslauthd -r -n 5 root 24697 0.0 0.4 151936 76544 ? S May21 0:03 /usr/sbin/saslauthd -a pam -c -m /var/spool/postfix/var/run/saslauthd -r -n 5 root 24698 0.0 0.4 151952 76536 ? S May21 0:03 /usr/sbin/saslauthd -a pam -c -m /var/spool/postfix/var/run/saslauthd -r -n 5 I'm struggling to work out how to troubleshoot this further as I'm not sure how to log the errors in saslauthd. These are the additional lines opening secure auth in etc/postfix/master.cf smtp inet n - - - - smtpd # Added 2525 to open smtp on this port for clients where port 25 is blocked by the isp. 2525 inet n - - - - smtpd #smtp inet n - - - 1 postscreen #smtpd pass - - - - - smtpd #dnsblog unix - - - - 0 dnsblog #tlsproxy unix - - - - 0 tlsproxy submission inet n - - - - smtpd -o syslog_name=postfix/submission -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING smtps inet n - - - - smtpd -o syslog_name=postfix/smtps -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING And here is the content of etc/postfix/sasl/smtpd.conf pwcheck_method: saslauthd mech_list: plain login allow_plaintext: true auxprop_plugin: sql sql_engine: mysql sql_hostnames: 127.0.0.1 sql_user: ispconfig sql_passwd: xxxxxxxxxxxxxxxxxxxxxx sql_database: dbispconfig sql_select: select password from mail_user where login = '%u@%r' and postfix = 'y' Any suggestions as to how to fix this would be greatly appreciated, even if it's just a way to detect the error automatically so I can restart the service without the user realising there was an issue. My system is Debian Wheezy, ISPConfig 3.0.5.3, Courier based on the latest perfect server build
You should be able to monitor saslauthd with monit. The monit config should be like this: Code: #saslauthd check process saslauthd with pidfile /var/spool/postfix/var/run/saslauthd/saslauthd.pid group mail start program = "/etc/init.d/saslauthd start" stop program = "/etc/init.d/saslauthd stop" if failed unix /var/spool/postfix/var/run/saslauthd/mux then restart if 5 restarts within 5 cycles then timeout depends on saslauthd_bin check file saslauthd_bin with path /usr/sbin/saslauthd group mail if failed checksum then unmonitor if failed permission 755 then unmonitor if failed uid root then unmonitor if failed gid root then unmonitor To debug saslauthd, add "-d" in the OPTIONS line in /etc/default/saslauthd and restart saslauthd. The verbose output should be in the syslog then.
Thanks Till for the advice with Monit. Just looking at getting saslauthd into debug mode as described above and there are numerous warnings suggesting not to enter it as an option under /etc/default/saslauthd as this will prevent the system from booting properly as the -d makes it run in the foreground rather than a daemon. I presume I should just stop the daemon (/etc/ini.d/saslauthd stop) and then start saslauthd in the foreground with all the existing options and the -d to debug ie: saslauthd -c -m /var/spool/postfix/var/run/saslauthd -r -d
Just to clarify for anyone reading this the actual command I had to run to saslauthd to run in debug from the command line was: saslauthd -a pam -n 5 -c -m /var/spool/postfix/var/run/saslauthd -r -d as you need to include the -a for the authentication mechanism, in my case spam, and the -n just gives the number of threads. Anyway after doing this and searching the logs a little more, something I'm not always so good at, I did find under the auth.log that the error I'm getting is: saslauthd[24693]: DEBUG: auth_pam: pam_authenticate failed: Memory buffer error Whilst this doesn't necessarily help me fix what's causing the issue I can a least monitor the log through a script and simply email the error and restart saslauthd when it happens which should make it unnoticeable to our users. Of course I could also just restart saslauthd once a day and that would also fix the issue from a user perspective but.... Till, can you point me in the right direction with this error? Thanks for your help so far.
I had the same problem and ended up setting up a cron job to restart it every night. I know it's a bad solution, but it works well and the service is only down for a few seconds.
Thanks Jon, Having written a script to check the logs, I have to say I've just ended up implementing an auto restart once a day via crontab simply because it adds zero extra load compared to reading the auth.log every minute. As you say it's not pretty but effective, even if it doesn't feel right. If anyone actually has a proper fix for this please let us know.
Eventhough this last post is quite a while ago, I just faced the same issue, running ISCOnfig on a Debian Wheezy. While saerching for that memory leak thing, I came across this source: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758660 Which is common to my setup is using the mysql plugin as well, and the comment of that might cause a memory leak. Eventhough I wonder why this happens out of a sudden, as I also did not see so many failed attempts on smtp/pop3/imap which could indicate more load and leaking memory for SASL. I just wonder if the suggested patch for the pam mysql module could make it into debian's repo: http://sourceforge.net/p/pam-mysql/bugs/27/#c2aa Any idea how to find that out?
