Post-installation script fails on systems with too little memory

[Andrew Starr-Bochicchio]

This is on a fresh trusty install.

Setting up mysql-server-5.6 (5.6.16-1~exp1) ...
2014-04-25 17:26:44 0 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead.
2014-04-25 17:26:44 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
start: Job failed to start
invoke-rc.d: initscript mysql, action "start" failed.
dpkg: error processing package mysql-server-5.6 (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 mysql-server-5.6
E: Sub-process /usr/bin/dpkg returned an error code (1)

tail /var/log/upstart/mysql.log
Check that mysqld is running and that the socket: '/var/run/mysqld/mysqld.sock' exists!
AppArmor parser error for /etc/apparmor.d/usr.sbin.mysqld in /etc/apparmor.d/usr.sbin.mysqld at line 44: Could not open 'local/usr.sbin.mysqld'
/usr/bin/mysqladmin: connect to server at 'localhost' failed
error: 'Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)'
Check that mysqld is running and that the socket: '/var/run/mysqld/mysqld.sock' exists!
2014-04-25 17:26:53 0 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead.
2014-04-25 17:26:53 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
/usr/bin/mysqladmin: connect to server at 'localhost' failed
error: 'Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)'
Check that mysqld is running and that the socket: '/var/run/mysqld/mysqld.sock' exists!

[James Page (james-page)]

Andrew

How much memory does you installation have? The default innodb buffer pool size increased in 5.6 and I'm wondering if this is the issue you are hitting?

[Andrew Starr-Bochicchio (andrewsomething)]

On Mon, Apr 28, 2014 at 4:57 AM, James Page <email address hidden> wrote:
> How much memory does you installation have? The default innodb buffer
> pool size increased in 5.6 and I'm wondering if this is the issue you
> are hitting?

That sounds like it might be it. This is on a 512MB VPS. I'll try to
reproduce on something larger.

Thanks!

[Arnaud Koëbel (arnaud-koebel)]

I ran into this. The standard config needs the /etc/apparmor.d/local/usr.sbin.mysqld file to be present or mysql won't start.
A simple "touch /etc/apparmor.d/local/usr.sbin.mysqld" solved the installation problem for me.

[Mike Sasso (1-mike-p)]

I ran into this problem when I fired up an AWS EC2 micro instance (which provides 512MB) with trusty and, on my brand spanking new server, tried to run sudo apt-get install mysql-server-5.6. I tried Arnaud's suggestion on another brand spanking new micro trusty server, but no luck. However, when I fired up a trusy VM with 2GB of memory using Oracle VM Virtualbox, the MySQL 5.6 installation sailed through without a hitch. So memory certainly does appear to be the issue.

In practice this sure does suggest that there's no longer a way to load the latest LTS version of Ubuntu Server onto an EC2 micro instance and then install the latest version of MySQL that's available via apt-get....

[Arnaud Koëbel (arnaud-koebel)]

Strange. I just tested this on a fresh 14.04 VM with 512Mb RAM.

From the original message :
"AppArmor parser error for /etc/apparmor.d/usr.sbin.mysqld in /etc/apparmor.d/usr.sbin.mysqld at line 44: Could not open 'local/usr.sbin.mysqld'", the apparmor problem seems clear.

That doesn't mean there isn't something else wrong.

On my new setup, MySQL 5.6 installed without trouble (created my empty file beforehand. I'll have to check it without) and runs. It requires 1.1 Gb of virtual RAM, but only occupies 440Mb at startup, so it runs fine (granted, it should run into trouble soon). Maybe the difference is what other packages you installed : apache2 itself would eat enough RAM to OOM a machine on Mysql install.

The innodb buffer pool seems to be 128Mb on my machine, which is the official default value.
mysqlcalculator states that RAM usage at 128Mb buffer pool is close to 700Mb (to be compared with the 576Mb RAM occupied by the previous 8Mb 5.5 default buffer pool) => Neither should be able to run out of the box with 512Mb RAM only.

With small machines, I think your best bet would be to deploy a my.cnf file prior to the mysql package installation (or to put a file in /etc/mysql/conf.d) with some alterations to the configuration (max_connections = 50 alone shaves 200Mb off RAM requirements) to ensure mysql will start and run fine.

[Mike Sasso (1-mike-p)]

Thanks, Arnaud, squishing down max_connections before attempting to install did the trick! I took the conf.d route and put a .cnf file in /etc/mysql/conf.d that contained two lines:

[mysqld]
max_connections = 20

Installing MySQL was the first thing I did on the first login to a new EC2 micro instance, so I definitely find it interesting that there are 512MB environments where the default MySQL 5.6 installation sails through and 512MB environments (AWS EC2!) where it crashes and burns. Obviously something is different. (I have lots of Windows experience, but I'm a Linux newbie. So I haven't a clue....)

[Launchpad Janitor (janitor)]

[Expired for mysql-5.6 (Ubuntu) because there has been no activity for 60 days.]

[Léon Hagenaars-Keus (hagenaarsdotnu)]

Same result here, though the situation is different, as my physical home-server has 3.8 gig ram and 4 gig swap.
At the moment of install, at least 3 gig is available for mysql and the whole swap is still empty.
Still the install won't finish.

[Robie Basak (racb)]

It seems to me that the original problem reported was solved by using a system with more memory, and that an appropriate workaround is to reduce max_connections on low memory systems. I don't think it's appropriate to reduce this setting by default, so I think this bug warrants "Won't Fix" status though I am happy to reconsider if somebody objects and does think the default should be lower for all Ubuntu users.

Léon, there are many reasons that a postinst might fail, and this bug is only one of them. If your postinst is failing for a different reason, please file a separate bug if you want your bug tracked or fixed. This bug tracks the failure due to low memory, and it is not useful to conflate it with other, separate issues which might need separate fixes.

[Léon Hagenaars-Keus (hagenaarsdotnu)]

Sorry Robie, my issue disappeared, a zentyal.cnf for mysql was wreaking havoc. zentyal removed=>issue gone.

[tmnuwan12 (tmnuwan12-soc)]

Yes. I was running Vagrant and I had to increase the memory to 1024MB of the VM. Increasing the memory worked for me.

Thanks a lot. Hope this helps someone.