Upgrading MySQL = Breaking Postfix

I never realized this until today, but apparently ever since I upgraded MySQL to version 5 the other day, my courier/postfix setup has been broken. I noticed I had over 80mb of stuff in /var/spool/postfix/maildrop, and skimming over some of the files, found that the root of all the problems seems to be the lack of connecting to MySQL. For example:

postfix/trivial-rewrite[9071]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock'

Many of the errors are MySQL-related, or related to the other processes failing that wanted MySQL, so this is obviously my culprit. Now, I know upgrading from MySQL 4 to 5 did some things to the passwords, because I remember having an issue once before on a different server, where older clients weren't able to connect until I went in and manually set the MySQL passwords for the database(s) in question to support the older password style (with OLD_PASSWORD). But I remember that when I upgraded MySQL this time, it prompted me to do that, and upon looking in the database, all passwords appear to be using the older style.

I'm not as fluent in the workings of postfix as I want to be, so I'm not sure what all information I should post in regards to fixing this (aside from me running Debian Sarge), but I wanted to at least ask now as I continue to poke around trying to fix it, in case someone else has had a similar issue before. Thanks in advance!

3 Replies

Normally I'd delete my post since I already fixed the problem, but hey, it might help someone else.

I came to find that my chroot jail for Courier had the problem, for whatever reason. Despite it showing up in a 'mount', the directory I bound into there appeared empty when I'd try to list its contents. So I checked fstab to double-check:

/var/run/mysqld /var/spool/postfix/var/run/mysqld auto bind 0 0

Then unmounted it, mount-a, and it worked fine again. No idea what caused it to muck up.

Then I realized it's kind of stupid to keep relying on this roundabout method of talking to mysql in the first place. So I looked up info on Courier's /etc/courier/authmysqlrc, commented out MYSQLSOCKET, added in a MYSQLPORT to go with the MYSQL_SERVER, restarted Courier and postfix's daemons, but it doesn't seem to work. So I'm not sure what to do on that front to avoid using the socket, but at least it works again the original way.

You might have 'skip-networking' in your MySQL config. If you do, then a socket is how you'd communicate with the MySQL server. You should probably use "bind-address = 127.0.0.1" instead.

@FyberOptic:

/var/run/mysqld /var/spool/postfix/var/run/mysqld auto bind 0 0

Then unmounted it, mount-a, and it worked fine again. No idea what caused it to muck up.

At a guess, the mysql upgrade deleted and then recreated /var/run/mysqld. The bind mounted pointed at the old directory, while mysql was using the new one.

Reply

Please enter an answer
Tips:

You can mention users to notify them: @username

You can use Markdown to format your question. For more examples see the Markdown Cheatsheet.

> I’m a blockquote.

I’m a blockquote.

[I'm a link] (https://www.google.com)

I'm a link

**I am bold** I am bold

*I am italicized* I am italicized

Community Code of Conduct