msyql configuration via dbconfig-common not picked up by initctl automatically during installation

[Paul Gevers]

I am running Kubuntu from USB stick and installing mysql-server-5.5.

mysqld does not start up properly because the configuration is not picked up automatically. After forcing "initctl reload-configuration" everything goes all right (see below). I am not sure if myql should fix this, if it is due to the fact that I run it from usb key or that dbconfig-common should fix it.

The issue is:
start: Unknown job: mysql
invoke-rc.d: initscript mysql, action "start" failed.
dpkg: error processing mysql-server-5.5 (--configure):

Full install output is:

kubuntu@kubuntu:~$ sudo start mysql
start: Unknown job: mysql
kubuntu@kubuntu:~$ sudo apt-get install mysql-server-5.5
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
  mysql-server-core-5.5
Suggested packages:
  tinyca mailx
The following NEW packages will be installed:
  mysql-server-5.5 mysql-server-core-5.5
0 upgraded, 2 newly installed, 0 to remove and 615 not upgraded.
Need to get 0 B/14.5 MB of archives.
After this operation, 49.5 MB of additional disk space will be used.
Do you want to continue [Y/n]?
Preconfiguring packages ...
Selecting previously unselected package mysql-server-core-5.5.
(Reading database ... 108871 files and directories currently installed.)
Unpacking mysql-server-core-5.5 (from .../mysql-server-core-5.5_5.5.22-0ubuntu1_i386.deb) ...
Selecting previously unselected package mysql-server-5.5.
Unpacking mysql-server-5.5 (from .../mysql-server-5.5_5.5.22-0ubuntu1_i386.deb) ...
Processing triggers for man-db ...
Processing triggers for ureadahead ...
Setting up mysql-server-core-5.5 (5.5.22-0ubuntu1) ...
Setting up mysql-server-5.5 (5.5.22-0ubuntu1) ...
120411 22:07:11 [Note] Plugin 'FEDERATED' is disabled.
120411 22:07:11 InnoDB: The InnoDB memory heap is disabled
120411 22:07:11 InnoDB: Mutexes and rw_locks use GCC atomic builtins
120411 22:07:11 InnoDB: Compressed tables use zlib 1.2.3.4
120411 22:07:11 InnoDB: Initializing buffer pool, size = 128.0M
120411 22:07:11 InnoDB: Completed initialization of buffer pool
120411 22:07:11 InnoDB: highest supported file format is Barracuda.
120411 22:07:11 InnoDB: Waiting for the background threads to start
120411 22:07:12 InnoDB: 1.1.8 started; log sequence number 1595675
120411 22:07:12 InnoDB: Starting shutdown...
120411 22:07:13 InnoDB: Shutdown completed; log sequence number 1595675
start: Unknown job: mysql
invoke-rc.d: initscript mysql, action "start" failed.
dpkg: error processing mysql-server-5.5 (--configure):
 subprocess installed post-installation script returned error exit status 1
No apport report written because MaxReports is reached already
                                                              Errors were encountered while processing:
 mysql-server-5.5
E: Sub-process /usr/bin/dpkg returned an error code (1)
kubuntu@kubuntu:~$ sudo initctl reload-configuration
kubuntu@kubuntu:~$ sudo apt-get install mysql-server-5.5
Reading package lists... Done
Building dependency tree
Reading state information... Done
mysql-server-5.5 is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 615 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue [Y/n]?
Setting up mysql-server-5.5 (5.5.22-0ubuntu1) ...
mysql start/running, process 1664
kubuntu@kubuntu:~$

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: mysql-server-5.5 5.5.22-0ubuntu1
ProcVersionSignature: Ubuntu 3.2.0-12.21-generic-pae 3.2.2
Uname: Linux 3.2.0-12-generic-pae i686
NonfreeKernelModules: wl
ApportVersion: 1.91-0ubuntu1
Architecture: i386
CasperVersion: 1.302
Date: Wed Apr 11 22:12:49 2012
LiveMediaBuild: Kubuntu 12.04 LTS "Precise Pangolin" - Alpha i386 (20120201)
Logs.var.log.daemon.log:

Logs.var.log.kern.log:

MySQLConf.etc.mysql.conf.d.mysqld.safe.syslog.cnf:
 [mysqld_safe]
 syslog
MySQLVarLibDirListing: False
ProcEnviron:
 LANGUAGE=
 TERM=xterm
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: mysql-5.5
UpgradeStatus: No upgrade log present (probably fresh install)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Clint Byrum (clint-fewbar)]

Is this really a problem with mysql? If upstart is missing a new job file, I think this is most likely caused by some problem with inotify or upstart itself, not mysql or its maintainer scripts. Is your system using overlayfs? IIRC, inotify does not work with overlayfs, which is why aufs was re-instated for the precise kernel, but perhaps your system still uses overlayfs?

[Paul Gevers (paul-climbing)]

> Is this really a problem with mysql?

As I said in my original bug report, I am not sure, see below.

> If upstart is missing a new job file, I think this is most likely
> caused by some problem with inotify or upstart itself, not mysql or
> its maintainer scripts.

Indeed, that is also why I also mentioned the usb stick. Isn't inotify
integrated in the file system? I suspect this issue result from the fact
that the stick has vfat fs.

> Is your system using overlayfs? IIRC, inotify does not work with
> overlayfs, which is why aufs was re-instated for the precise kernel,
> but perhaps your system still uses overlayfs?

So my question: could the same problem be with vfat? And if so, where
should this bug go, to upstart (to check for the file system)?

Paul
By the way, the bugs I set as duplicates yesterday are probably not dups
of this bug, but more likely related to bug 986892.

[Miguel Gonzalez (miguel-3-gonzalez)]

We all have followed the instructions from you.

With a new fresh install, purging using dpkg after unsuccesfully trying to install mysql-server-5.5:

initctl reload-configuration and reinstall still breaks

Any work around to install at least an old version? We are stuck and can't install mysql server (or upgrade)

Thanks,

Miguel

[Paul Gevers (paul-climbing)]

@Miguel,

> Any work around to install at least an old version? We are stuck and
> can't install mysql server (or upgrade)

Please have a look at bug 986892.

Check if you have the file /etc/apparmor.d/local/usr.sbin.mysqld

If not create the file, e.g by running
touch /etc/apparmor.d/local/usr.sbin.mysqld
with the appropriate permissions (e.g. using sudo) and see if it helps.
If it works please let us know.

Paul

[Miguel Gonzalez (miguel-3-gonzalez)]

I have just did what you said:

Setting up mysql-server-5.5 (5.5.22-0ubuntu1) ...
120506 20:35:23 [Note] Plugin 'FEDERATED' is disabled.
120506 20:35:23 InnoDB: The InnoDB memory heap is disabled
120506 20:35:23 InnoDB: Mutexes and rw_locks use GCC atomic builtins
120506 20:35:23 InnoDB: Compressed tables use zlib 1.2.3.4
120506 20:35:23 InnoDB: Initializing buffer pool, size = 128.0M
120506 20:35:23 InnoDB: Completed initialization of buffer pool
120506 20:35:23 InnoDB: highest supported file format is Barracuda.
120506 20:35:23 InnoDB: Waiting for the background threads to start
120506 20:35:24 InnoDB: 1.1.8 started; log sequence number 1595675
120506 20:35:24 InnoDB: Starting shutdown...
120506 20:35:25 InnoDB: Shutdown completed; log sequence number 1595675
start: Job failed to start
invoke-rc.d: initscript mysql, action "start" failed.
dpkg: error processing mysql-server-5.5 (--configure):
 subprocess installed post-installation script returned error exit status 1
dpkg: dependency problems prevent configuration of mysql-server:
 mysql-server depends on mysql-server-5.5; however:
  Package mysql-server-5.5 is not configured yet.
dpkg: error processing mysql-server (--configure):
 dependency problems - leaving unconfigured
Processing triggers for libc-bin ...
No apport report written because the error message indicates its a followup error from a previous failure.
                          ldconfig deferred processing now taking place
Errors were encountered while processing:
 mysql-server-5.5
 mysql-server
E: Sub-process /usr/bin/dpkg returned an error code (1)

root@s16224997:/etc/apparmor.d# ls -l
total 40
drwxr-xr-x 3 root root 4096 Apr 19 19:38 abstractions
drwxr-xr-x 2 root root 4096 Apr 19 19:39 cache
drwxr-xr-x 2 root root 4096 Apr 19 19:20 disable
drwxr-xr-x 2 root root 4096 Mar 7 17:11 force-complain
drwxr-xr-x 2 root root 4096 May 6 20:34 local
-rw-r--r-- 1 root root 2139 Mar 8 01:29 sbin.dhclient
drwxr-xr-x 4 root root 4096 Apr 19 19:38 tunables
-rw-r--r-- 1 root root 1046 Mar 30 06:48 usr.sbin.mysqld
-rw-r--r-- 1 root root 1393 Mar 7 16:41 usr.sbin.rsyslogd
-rw-r--r-- 1 root root 1418 Jan 3 16:55 usr.sbin.tcpdump

Now the usr.sbin.mysqld file as you see it's not empty

Miguel

[Miguel Gonzalez (miguel-3-gonzalez)]

I forgot:

root@s16224997:/etc/apparmor.d/local# ls -l
total 16
-rw-r--r-- 1 root root 1111 Mar 23 00:03 README
-rw-r--r-- 1 root root 120 Apr 19 19:20 sbin.dhclient
-rw-r--r-- 1 root root 0 May 6 20:43 usr.sbin.mysqld
-rw-r--r-- 1 root root 124 Apr 19 19:20 usr.sbin.rsyslogd
-rw-r--r-- 1 root root 123 Apr 19 19:25 usr.sbin.tcpdump

[Miguel Gonzalez (miguel-3-gonzalez)]

I'm sorry, why this bug (and duplicates) are not labeled as critical? Many apps rely on MySQL.

[Miguel Gonzalez (miguel-3-gonzalez)]

I've fixed it following these instructions:

http://www.masaokitamura.com/2011/04/mysql-disable-apparmor-to-fix-permissions-problems/

root@myserver:/etc/apparmor.d# mv usr.sbin.mysqld .usr.sbin.mysqld
root@myserver:/etc/apparmor.d# /etc/init.d/apparmor restart
 * Reloading AppArmor profiles
Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd
AppArmor parser error for /etc/apparmor.d/sbin.dhclient in /etc/apparmor.d/tunables/global at line 17: Could not open 'tunables/proc'
AppArmor parser error for /etc/apparmor.d/usr.sbin.tcpdump in /etc/apparmor.d/tunables/global at line 17: Could not open 'tunables/proc'
root@myserver:/etc/apparmor.d# /etc/init.d/apparmor status
apparmor module is loaded.
0 profiles are loaded.
0 profiles are in enforce mode.
0 profiles are in complain mode.
0 processes have profiles defined.
0 processes are in enforce mode.
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.

root@myserver:/etc/apparmor.d# mysql -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 42
Server version: 5.5.22-0ubuntu1 (Ubuntu)

Copyright (c) 2000, 2011, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql>
mysql> quit
Bye

[Paul Gevers (paul-climbing)]

Hi Miguel,

> root@s16224997:/etc/apparmor.d/local# ls -l
> -rw-r--r-- 1 root root 0 May 6 20:43 usr.sbin.mysqld

The timestamp of this file is after your previous post. Did the update
now succeed or didn't it?

Paul
By the way, did you file one of the duplicates of this bug (982303)? It
should most likely be "unduplicated" from this bug, and if you can now
install mysqld, be duplicate of bug 986892.

[Miguel Gonzalez (miguel-3-gonzalez)]

By the way, I tried again without performing touch in local apparmor previously and just doing:

root@myserver:/etc/apparmor.d# mv usr.sbin.mysqld .usr.sbin.mysqld

no need to restart apparmor, just issueing again apt-get install mysql-server worked

[Miguel Gonzalez (miguel-3-gonzalez)]

Yes, it succeeded when I performed just a rename of the usr.sbin.mysqld under /etc/apparmor.d

So my guess is that something is broken under the mysqld file in apparmor that needs to be fixed.

I didn't file any bug. By the way, this is in a new fresh install of precise.

Miguel

[Dr. Christian Knebel (knebel)]

The hint of Miguel did it for me! Thanks!!!

[Clint Byrum (clint-fewbar)]

I have tested installing mysql-server-5.1 in 11.10, and then doing a dist-upgrade to get to precise.

Ok so the problem is that mysql-server-5.1's postrm runs *after* mysql-server-5.5's postinst creates the file. This is because we only have a 'Breaks+Replaces' relationship between the two, so dpkg correctly:

* deconfigures 5.1
* installs 5.5
* configures 5.5
* removes 5.1

This really does need to be fixed in dh_apparmor. The postrm snippet should simply not rm the local/ file if the primary file is still in existence, since it is basically guaranteed to still depend on the local/ file.