Go Back   HowtoForge Forums | HowtoForge - Linux Howtos and Tutorials > ISPConfig 3 > General

Do you like HowtoForge? Please consider supporting us by becoming a subscriber.
Reply
 
Thread Tools Display Modes
  #11  
Old 4th November 2011, 09:26
till till is offline
Super Moderator
 
Join Date: Apr 2005
Location: Lüneburg, Germany
Posts: 35,421
Thanks: 812
Thanked 5,205 Times in 4,081 Posts
Default

Quote:
Postfix uses no longer MySQL to ask for data, but flat files.

Is there a chance that ISPConfig produces those flat file on demand? I think it was like this back in IPSConfig 2...?
Youcan write a plugiun for that. But we dont plan to change the postfix setup in ipconfig 3. I really understand that you have a problem there with your installation but if there are thousands of installations which are much larger then your setup and none of these have this problem, then there is no reason to change the setup.

So instead of talking to change a etup which has prooven to work reliably an many systems, you shoul try to debug your mysql server by enabling mysql logging to see why postfix is not able to connect to mysql.
__________________
Till Brehm
--
Get ISPConfig support and the ISPConfig 3 manual from ispconfig.org.
Reply With Quote
Sponsored Links
  #12  
Old 4th November 2011, 10:07
ande ande is offline
Junior Member
 
Join Date: Jan 2008
Location: Freiburg, Germany
Posts: 29
Thanks: 5
Thanked 0 Times in 0 Posts
Default

Quote:
Originally Posted by till View Post
So instead of talking to change a etup which has prooven to work reliably an many systems, you shoul try to debug your mysql server by enabling mysql logging to see why postfix is not able to connect to mysql.
I did that already and have seen and when that happens, I see not even a query in the MYSQL log. The lock must have happened before. Postfix shown an error without having passed the query to MYSQL - that is what I think I see.

If it would be your server and your customers, what would you do instead?
Reply With Quote
  #13  
Old 4th November 2011, 10:25
till till is offline
Super Moderator
 
Join Date: Apr 2005
Location: Lüneburg, Germany
Posts: 35,421
Thanks: 812
Thanked 5,205 Times in 4,081 Posts
Default

Quote:
If it would be your server and your customers, what would you do instead?
1) Is this a vserver that uses openvz or virtuozzo? If yes, then check with:

cat /proc/user_beancounters

if you hit any limits.

2) Try to get more verbose infos from postfix: http://www.postfix.org/DEBUG_README.html

3) E.g. create a new server from scratch as virtual server (works fine on a desktop pc with vmware or other free virtualisation software) and then check if you can reproduce the problem there and if not, compare the relevant config files for postfix and mysql.
__________________
Till Brehm
--
Get ISPConfig support and the ISPConfig 3 manual from ispconfig.org.
Reply With Quote
  #14  
Old 4th November 2011, 11:43
ande ande is offline
Junior Member
 
Join Date: Jan 2008
Location: Freiburg, Germany
Posts: 29
Thanks: 5
Thanked 0 Times in 0 Posts
Default

It appears that both amavis and postfix (trivial-rewrite and smtp) are sometimes not able to access MySQL. I turned on -v for smtp and trivial-rewrite:

Quote:
>>> START Client host RESTRICTIONS <<<
Nov 4 11:38:57 eins postfix/smtpd[8001]: generic_checks: name=check_client_access
Nov 4 11:38:57 eins postfix/smtpd[8001]: check_namadr_access: name unknown addr 95.86.108.61
Nov 4 11:38:57 eins postfix/smtpd[8001]: check_domain_access: unknown
Nov 4 11:38:57 eins postfix/smtpd[8001]: dict_mysql_get_active: found active connection to host 127.0.0.1
Nov 4 11:38:57 eins postfix/smtpd[8001]: warning: mysql query failed: MySQL server has gone away
Nov 4 11:38:57 eins postfix/smtpd[8001]: warning: mysql:/etc/postfix/mysql-virtual_client.cf: table lookup problem
Nov 4 11:38:57 eins postfix/smtpd[8001]: check_table_result: mysql:/etc/postfix/mysql-virtual_client.cf 451 4.3.5 Server configuration error unknown
Nov 4 11:38:57 eins postfix/smtpd[8001]: NOQUEUE: reject: RCPT from unknown[95.86.108.61]: 451 4.3.5 <unknown[95.86.108.61]>: Client host rejected: Server configuration error; from=<heuer@xxx.de> to=<heuer@forum-vauban.de> proto=ESMTP helo=<95.86.108.61>
Nov 4 11:38:57 eins postfix/smtpd[8001]: generic_checks: name=check_client_access status=2
Nov 4 11:38:57 eins postfix/smtpd[8001]: > unknown[95.86.108.61]: 451 4.3.5 <unknown[95.86.108.61]>: Client host rejected: Server configuration error
Nov 4 11:38:57 eins postfix/trivial-rewrite[8114]: connection closed fd 129
Nov 4 11:38:57 eins postfix/smtpd[8001]: smtp_get: EOF
Port 3306 is open (needed for replication) and socket might be as well functioning.

Might it be that Postfix thinks a connection is still open while MySQL already closed it?

Last edited by ande; 4th November 2011 at 11:45.
Reply With Quote
  #15  
Old 4th November 2011, 11:49
till till is offline
Super Moderator
 
Join Date: Apr 2005
Location: Lüneburg, Germany
Posts: 35,421
Thanks: 812
Thanked 5,205 Times in 4,081 Posts
Default

Whats with 1)?
__________________
Till Brehm
--
Get ISPConfig support and the ISPConfig 3 manual from ispconfig.org.
Reply With Quote
  #16  
Old 4th November 2011, 13:49
ande ande is offline
Junior Member
 
Join Date: Jan 2008
Location: Freiburg, Germany
Posts: 29
Thanks: 5
Thanked 0 Times in 0 Posts
Default

I have no virtual server, but "real iron".

However, since I added

wait_timeout = 1800
connect_timeout = 60

in /etc/mysql/my.cnf

- this seemed to solve the problem so far.

As far as I think, postfix was relying on open TCP connections where MySQL closed them already.

Next week, I will revert all the other changes I made to identify the "culprit". But now my customers deserve some peace :-)

Postfix logging is really great, BTW.

My current my.cnf without any comments:

Code:
[client]
port		= 3306
socket		= /var/run/mysqld/mysqld.sock
[mysqld_safe]
socket		= /var/run/mysqld/mysqld.sock
nice		= 0
[mysqld]
user		= mysql
pid-file	= /var/run/mysqld/mysqld.pid
socket		= /var/run/mysqld/mysqld.sock
port		= 3306
basedir		= /usr
datadir		= /var/lib/mysql
tmpdir		= /tmp
language	= /usr/share/mysql/english
skip-external-locking
skip-locking

key_buffer		= 384M
max_allowed_packet	= 64M
thread_stack		= 192K
thread_cache_size       = 8
myisam-recover         = BACKUP

max_connections        = 500
max_user_connections   = 500
wait_timeout = 1800
connect_timeout = 60
table_cache            = 4096
sort_buffer_size = 2M
read_buffer_size = 2M
read_rnd_buffer_size = 64M
myisam_sort_buffer_size = 64M
query_cache_size = 32M

query_cache_limit	= 1M
query_cache_size        = 16M
# Anpassung fuer die Replikation
# ande 20111102
server-id                = 1
log-bin                  = /var/log/mysql/mysql-bin.log
log-error                = /var/log/mysql/mysql-bin.err
log-slave-updates
expire_logs_days         = 30
max_binlog_size          = 100M
binlog_do_db             = xxxxxxx
auto_increment_increment = 10
auto_increment_offset    = 1
replicate-same-server-id = 0
skip-innodb
[mysqldump]
quick
quote-names
max_allowed_packet	= 64M
[mysql]
[isamchk]
key_buffer		= 16M
!includedir /etc/mysql/conf.d/

Last edited by ande; 4th November 2011 at 13:52.
Reply With Quote
  #17  
Old 17th March 2012, 01:16
Turbanator Turbanator is offline
Senior Member
 
Join Date: Jun 2008
Posts: 216
Thanks: 21
Thanked 16 Times in 16 Posts
Default maybe a solution

Sorry to reopen this but i've had this problem for the longest time on Lenny.

Here is the change I JUST made (so no results yet).

http://wiki.bacula.org/doku.php?id=f..._has_gone_away

Seems to be a simple lengthening of wait_timeout to a 24 hr value.

If this doesn't fix, I'll post back.

-T
Reply With Quote
  #18  
Old 6th November 2012, 16:37
Dehumanizer Dehumanizer is offline
Junior Member
 
Join Date: Oct 2012
Posts: 16
Thanks: 1
Thanked 2 Times in 1 Post
Post

I can confirm that increasing wait_time in mysql config seems to help with this issue. I recently had this problem and after setting wait_time to 3600 (i.e. 1 hour), "table lookup problem" and "MySQL server has gone away" errors stopped appearing.

From what I have found, the default behaviour of auto reconnecting has changed between mysql 5.0 and 5.1 and with 5.1 the default client behaviour is not to reconnect after losing connection, which can be changed by enabling auto reconnections but the library used by postfix to connect to mysql probably counts on the auto reconnection and while with mysql 5.0 it reconnects automatically, with 5.1 it doesn't and the query can't be executed and it ends with an error.
Reply With Quote
  #19  
Old 7th November 2012, 17:51
concept21 concept21 is offline
Senior Member
 
Join Date: Dec 2011
Posts: 142
Thanks: 27
Thanked 14 Times in 11 Posts
Default

Check mysql error.log!!!

It may be a mysql db corruption!!!
Reply With Quote
  #20  
Old 7th November 2012, 17:53
Dehumanizer Dehumanizer is offline
Junior Member
 
Join Date: Oct 2012
Posts: 16
Thanks: 1
Thanked 2 Times in 1 Post
 
Default

No it itsn't. The database is clean, mysql reports no errors in error log and since increasing the wait_time I haven't got any errors in the posfix error log either.
Reply With Quote
Reply

Bookmarks

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Catchall and Forwarding not working simmo General 6 22nd March 2014 00:54
Postfix/courier/Centos 6 cant send email to external email servers maxtorzito Installation/Configuration 14 7th October 2011 10:56
mail authentication failure - unknown user or password evok Installation/Configuration 9 16th October 2010 06:37
Sending emails with custom FROM email address merisor Installation/Configuration 4 8th February 2010 16:27
Centos 4.4 32bit Hangs, High Server load 3cwired_com Server Operation 11 16th November 2006 15:47


All times are GMT +2. The time now is 01:48.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2014, vBulletin Solutions, Inc.