Confusing mysqld startup failure with apparmor (Hardy)

Thank you for using Ubuntu and taking the time to report a bug. It is planned to add extra information to both the profiles, the README.Debian and the configuration files for apparmor enforcing profiles. This should happen sometime after Beta is released.

This bug was fixed in the package mysql-dfsg-5.0 - 5.0.51a-3ubuntu3

---------------
mysql-dfsg-5.0 (5.0.51a-3ubuntu3) hardy; urgency=low

  [ Nicolas Valcárcel ]
  * Confirming password on install if given (LP: #162167)

  [ Jamie Strandboge ]
  * follow ApparmorProfileMigration and force apparmor complain mode on some
    upgrades (LP: #203531)
    - debian/control: Recommends apparmor >= 2.1+1075-0ubuntu6
    - debian/mysql-server-5.0.dirs: add etc/apparmor.d/force-complain
    - debian/mysql-server-5.0.preinst: create symlink for force-complain/
      on pre-feisty upgrades, upgrades where apparmor-profiles profile is
      unchanged (ie non-enforcing) and upgrades where the profile doesn't
      exist
    - debian/mysql-server-5.0.postrm: remove symlink in force-complain/ on
      purge
  * debian/additions/my.cnf: add warning about apparmor (LP: #201799)

 -- Mathias Gug <email address hidden> Tue, 25 Mar 2008 17:05:22 -0400

Yay! Got the fix today :-)

I installed mysql just a few minutes ago. This same bug still exists. How do we fix this?

Apr 26 10:00:00 laptap kernel: [ 6026.254152] audit(1209175200.933:26): type=1503 operation="inode_permission" requested_mask="rw::" denied_mask="rw::" name="/home/mysql/ibdata1" pid=15730 profile="/usr/sbin/mysqld" namespace="default"

daemon logs:

Apr 26 10:00:00 laptap mysqld[15731]: InnoDB: the directory.
Apr 26 10:00:00 laptap mysqld[15731]: InnoDB: File name ./ibdata1
Apr 26 10:00:00 laptap mysqld[15731]: InnoDB: File operation call: 'open'.
Apr 26 10:00:00 laptap mysqld[15731]: InnoDB: Cannot continue operation.
Apr 26 10:00:00 laptap mysqld_safe[15739]: ended
Apr 26 10:00:15 laptap /etc/init.d/mysql[15890]: 0 processes alive and '/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf ping' resulted in
Apr 26 10:00:15 laptap /etc/init.d/mysql[15890]: ^G/usr/bin/mysqladmin: connect to server at 'localhost' failed
Apr 26 10:00:15 laptap /etc/init.d/mysql[15890]: error: 'Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)'
Apr 26 10:00:15 laptap /etc/init.d/mysql[15890]: Check that mysqld is running and that the socket: '/var/run/mysqld/mysqld.sock' exists!
Apr 26 10:00:15 laptap /etc/init.d/mysql[15890]:

Packages installed:

un mysql-client <wala> (walang paglalarawan)
ii mysql-client-5.0 5.0.51a-3ubuntu5 MySQL database client binaries
ii mysql-common 5.0.51a-3ubuntu5 MySQL database common files
ii mysql-server 5.0.51a-3ubuntu5 MySQL database server (meta package depending on the latest version)
ii mysql-server-5.0 5.0.51a-3ubuntu5 MySQL database server binaries

I disabled app armor and now it is working.

/etc/init.d/apparmor stop
update-rc.d -f apparmor remove

We should really fix this since many are using this application in Ubuntu.

Alternative solution:

1. Edit /etc/apparmor.d/usr.sbin.mysqld and add the following two lines:

    /home/mysql/ r,
    /home/mysql/** rwk,

    somewhere in the middle of the file. After the /var/lib/mysql lines would be fine.
2. /etc/init.d/apparmor restart
3. /etc/init.d/mysql restart

You retain the benefis of apparmor. Maybe the comments in /etc/mysql/my.cnf regarding apparmor can be expanded to cover exactly what you should do if you reset mysql_data.

On Sat, Apr 26, 2008 at 02:37:54AM -0000, Rick Bahague Jr wrote:
> I disabled app armor and now it is working.
>
> /etc/init.d/apparmor stop
> update-rc.d -f apparmor remove
>
> We should really fix this since many are using this application in
> Ubuntu.

No. Do not do this. Please disable the _profile_ for mysqld
if it is causing problems:

  sudo apt-get install apparmor
  sudo touch /etc/apparmor.d/disable/usr.sbin.mysqld
  sudo /etc/init.d/apparmor start
  sudo /etc/init.d/mysqld restart

or, just flip the profile into complain mode:

  sudo aa-complain mysqld

better yet, fix the profile:

  sudo vi /etc/apparmor.d/*mysqld
  sudo /etc/init.d/mysqld restart

Do not remove the entire subsystem. :P

--
Kees Cook
Ubuntu Security Team

Hi everyone,

Thanks for the very immediate response. I followed Lost and Tokyo and Kess Cook fix. MySQL is now working. Maybe there should be some messages on MySQL installation saying to do the above if users change the default data directory.

Thanks guys.

Rick

followed the recommended steps and it didn't work when I type

sudo /etc/init.d/mysqld restart
sudo: /etc/init.d/mysqld: command not found

synpatic says I do have mysql-server-5.0 installed

toddq: you need to use 'sudo /etc/init.d/mysql restart' (no 'd' on the end of mysql there).

Cheers,
CMP

There must be a regression in Jaunty using:

mysql-server 5.1.30really5.0.75-0ubuntu10
apparmor 2.3+1289-0ubuntu14

because I just got this bug on a freshly installed Jaunty beta (with updates to 12th April).

How do I nominate a new task for this?

Just had the same issue and followed the steps provided by Lost In Tokyo. This did not work for me. I then followed the steps by Kees Cook. Working fine with it disabled.

I spent at least 3 hours trying to figure out what the cause of the issue was. My logs are identical, except I am moving the data to another drive mounted on the system. This is on Jaunty.

In addition to apparmor disallowing mysql user to write to other directories, it also is preventing the memlock option from working which forces mysql to use additional system memory instead of the disk for buffers, etc, greatly increasing performance.

mysql-server: 5.1.30really5.0.75-0ubuntu10.2
apparmor: 2.3+1289-0ubuntu14

Aisthesis, this bug is closed. Please open a new bug by following http://wiki.ubuntu.com/DebuggingApparmor. Thanks!