Symlinked MySQL Configuration File Problem

Say you are me and you are updating your MySQL configuration. Say that, for purposes of backup and version control, you replace /etc/mysql/my.cnf with a symlink. Say you stop MySQL and start it up again, and you receive a failure message.

You might venture to look at the service startup log file, perhaps /var/log/upstart/mysql.log. You might discover this error message:

Fatal error: Please read "Security" section of the manual to find out how to run mysqld as root!

You might, if you were me, spend several hours fruitlessly reading that manual and altering parts of the configuration files willy-nilly, to no avail.

At some point, you might become frustrated and just search for that error message, say on Google. That actually wouldn’t help much, because everyone else receiving the error appears to be receiving it for a different reason.

Eventually, you might guess that the symlinking caused the problem, and you would revert that step. And then MySQL would start to work.

This might be enough to satisfy you, but say you want to know exactly why. You might do another Google search, and come across a page entitled MySQL Not Reading Symlinks for Options Files my.cnf. You might be surprised to find that the symlink strategy fails because MySQL is run using AppArmor, and AppArmor is blocking MySQL from reading the symlinked file.

So you might edit the AppArmor configuration files to allow for access to the symlinked configuration file, and you might find that the error goes away.

Also, say you noticed that, for MySQL, there is both an upstart configuration file and a System V init.d file. You might wonder why both are included in the MySQL distribution. Luckily, you would quickly find that the System V file is not in any of the rc*.d directories, so it is never executed.