Processbounces results in Database error 2006

ℹ️ Support
#1

The output is like this:

phpList version 3.2.5 (c) 2000-2017 phpList Ltd, http://www.phplist.com
phpList - 60951 bounces to fetch from the mailbox
phpList - Please do not interrupt this process
phpList - Database error 2006 while doing query  MySQL server has gone away
phpList - Database error 2006 while doing query  MySQL server has gone away
(repeats thousands of lines)

I have also tried editing function processPop($server, $user, $password) in admin/processbounces.php :
from: return processMessages($link, 100000);
into: return processMessages($link, 500);

Something I saw duncanc suggest in a very old thread.

But it does not help.

#2

@kaon You have way too many bounces for phplist to process, so I suggest that you delete them from the mailbox and start accumulating again.

This might indicate that the mysql server has a very short timeout period. Possibly you could increase that but your hosting company might not allow that.

#3

And yet sometimes it works, and sometimes partially. Here’s what I find in the cron job output file:

phpList version 3.2.5 (c) 2000-2017 phpList Ltd, http://www.phplist.com
phpList - 58952 bounces to fetch from the mailbox
phpList - Please do not interrupt this process
phpList - 25 done
phpList - 50 done
phpList - 75 done
phpList - 100 done
phpList - 125 done
phpList - 150 done
phpList - 175 done
phpList - 200 done
phpList - 225 done
phpList - 250 done
phpList - 275 done
phpList - 300 done
phpList - Database error 2006 while doing query  MySQL server has gone away
phpList - Database error 2006 while doing query  MySQL server has gone away

I have set the ‘return processMessages($link, 500)’ to 500, and cron is every half hour. I hope it can get thru the backlog like this. I only just noticed that processbounces had been stuck for the past ~1 year.

UPDATE: I noticed that subsequent cron outputs showed the same output as the above, without any decrement of the “58952 bounces to fetch”. So I reduced the processbounces batch size from 500 to 250 to see what would happen… then I get ONE fully successful run (250 bounces), and then I get this:

phpList version 3.2.5 (c) 2000-2017 phpList Ltd, http://www.phplist.com
phpList - 58702 bounces to fetch from the mailbox
phpList - Please do not interrupt this process
phpList - 25 done
phpList - 50 done
phpList - Database error 2006 while doing query  MySQL server has gone away
phpList - Database error 2006 while doing query  MySQL server has gone away

So it seems like there is a constraint within PHPList / MySQL rather than from the pop mailbox.
Is there something I can clear / reset in the DB?

#4

@kaon Possibly one of the mysql timeout values is low, try running this in phpmyadmin

SHOW VARIABLES LIKE "%timeout%"

The value of wait_timeout might be low.
Otherwise try reducing even further the number of bounce emails that phplist tries to process in one run.

#5

Thank you Duncanc, do you see anything abnormal here?

Variable_name    Value
connect_timeout    10
delayed_insert_timeout    300
innodb_lock_wait_timeout    50
innodb_rollback_on_timeout    OFF
interactive_timeout    28800
lock_wait_timeout    31536000
net_read_timeout    30
net_write_timeout    60
slave_net_timeout    3600
wait_timeout    28800

Here are the row counts of some possibly related tables:

phplist_user_blacklist_data  35,634  utf8_general_ci  8.7 MiB
phplist_user_blacklist       35,633  utf8_general_ci  4.5 MiB
phplist_bounce               12,316  utf8_general_ci  215.9 MiB

Is there something I can do to flush the consecutive bounce mechanism? Or bounce rules?

#6

@kaon I though the wait_timeout might be low but it is not.

I suggest deleting the bulk of the emails from the mailbox directly,maybe keep a few thousand. There will be a lot of repeated bounces for email addresses so there is no point in trying to process them all.
Change the number of bounces that phplist handles in one run to a value that seems to work, say 50, and run the cron job more often.

1 Like
#7

Thank you duncanc, deleting the oldest 95% of bounces from the mailbox appears to have solved the problem.
I will know for sure in the coming months.