You are here

mysql respawning too fast, stopped & init: mysql post-start process (5075) terminated with status 1

Submitted by Druss on Tue, 2012-05-08 23:38

After my upgrade from Lucid to Precise (and thereby, from MySQL 5.1 to 5.5), I found that my MySQL instance was not running. When I tried to start the service all I got back was that it had failed to start.

I checked the system log (sudo tail /var/log/syslog) to see if I could divine the cause of this issue and I found the following messages:

init: mysql post-start process (5075) terminated with status 1
mysql respawning too fast, stopped

I didn't find them any more helpful than I reckon you do. A helpful chap on IRC advised me to try starting MySQL from the terminal, albeit not using the service command, but via the "no longer recommended" /etc/init.d route. This is something along the lines of what I saw when I did so:

root@stranger:/etc/init.d# mysqld start
120508 22:42:59 [Warning] Can't create test file /media/asimov/mysql/stranger.lower-test
120508 22:42:59 [Warning] Can't create test file /media/asimov/mysql/stranger.lower-test
120508 22:43:00 [Note] Plugin 'FEDERATED' is disabled.
mysqld: Can't find file: './mysql/plugin.frm' (errno: 13)
120508 22:43:00 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
120508 22:43:00 InnoDB: The InnoDB memory heap is disabled
120508 22:43:00 InnoDB: Mutexes and rw_locks use GCC atomic builtins
120508 22:43:00 InnoDB: Compressed tables use zlib
120508 22:43:00 InnoDB: Initializing buffer pool, size = 128.0M
120508 22:43:00 InnoDB: Completed initialization of buffer pool
120508 22:43:00  InnoDB: Operating system error number 13 in a file operation.
InnoDB: The error means mysqld does not have the access rights to
InnoDB: the directory.
InnoDB: File name ./ibdata1
InnoDB: File operation call: 'open'.
InnoDB: Cannot continue operation.

As you can see, I ran it as root and as you can also tell, it looked like it was an access issue possibly with the path /media/asimov/mysql/. The server in question is my local server and the aforementioned path is the data directory which is mounted on a different partition. Even though the directory had mysql as both its owner and group, the mysql service could not access it for some reason. Considering the relative lack of danger of experimenting with my dev server, I chanced playing with the permissions with a:
chmod -R 770 /media/asimov/mysql

The above statement would give "all" permissions to the owner and group (both currently set to mysql) which might seem safe enough, but is the kind of thing that can come back to bite you in the old Gluteus Maximus at a later date (well after this incident has left the mortal coil of living memory). Once I "reset" the permissions, I was able to successfully start mysql and all was well with the world once again.

If the above did not fix your problem, the following are other potential solutions that I came across on the net and on IRC:

  • Check that my.cnf exists in /etc/mysql/ and that there's only one of them around in the various config directories (as well as your own home directory, I guess).
  • Check that the apparmor entry for mysql exists and points to the right directories and files.
  • Reconfigure mysql using dpkg-reconfigure mysql-server-5.5
  • Avoid using an empty root password was another potential fix with a high frequency of repeats.
  • Reinstall mysql was also an oft recommended option. If you do, remember to back things up beforehand!

Good luck!