Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.
What I did before this happened:
But then, exactly 1 minute later, I get:
PDOException in Connector.php line 55: SQLSTATE[HY000] [2002] No such file or directory
at PDO->__construct('mysql:host=localhost;dbname=homestead', 'homestead', 'secret', array('0', '2', '0', false, false)) in Connector.php line 55
And my database connection in Sequel Pro gets disconnected as well.
So, after 1 minute it seems MySQL just stops working.
This happens every time after I vagrant up my homestead server.
What is going on?
@jlmmns ssh into your vagrant box (Homestead) and check the syslog, mysql en error logs. Not the laravel logs, but the logs found in /var/*
Also, try to restart mysql and see if there are any error message:
sudo service mysql restart
@renedekat Anything specific to look for in syslog? It's kind of huge...
Both mysql.log and mysql.err are empty. But there are a bunch of mariadb-bin... files under /var/log/mysql/
Restarting mysql gave nothing for a long while, and then returned the following:
Job for mariadb.service failed because a timeout was exceeded. See "systemctl status mariadb.service" and "journalctl -xe" for details.
@jlmmns Try running this command
sudo mysql_install_db --user=mysql --basedir=/usr/ --ldata=/var/lib/mysql/
And then restart mysql
@renedekat At the bottom of syslog it says the following:
Jun 30 14:32:16 homestead systemd[1]: Failed to start MariaDB database server.
Jun 30 14:32:16 homestead systemd[1]: mariadb.service: Unit entered failed state.
Jun 30 14:32:16 homestead systemd[1]: mariadb.service: Failed with result 'timeout'.
Jun 30 14:32:16 homestead systemd[1]: Reached target Multi-User System.
Jun 30 14:32:16 homestead systemd[1]: Reached target Graphical Interface.
Jun 30 14:32:16 homestead systemd[1]: Starting Update UTMP about System Runlevel Changes...
Jun 30 14:32:16 homestead systemd[1]: Started Update UTMP about System Runlevel Changes.
Jun 30 14:32:16 homestead systemd[1]: Startup finished in 5.405s (kernel) + 2min 31.646s (userspace) = 2min 37.052s.
Jun 30 14:35:01 homestead CRON[1694]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Jun 30 14:39:01 homestead CRON[1714]: (root) CMD ( [ -x /usr/lib/php/sessionclean ] && /usr/lib/php/sessionclean)
Maybe it has to do with CRON, since that runs every minute?
Maybe that's why my MySQL got disconnected after exactly 1 minute?
On my previous Homestead server I had cron running.
vagrant@homestead:~$ sudo mysql_install_db --user=mysql --basedir=/usr/ --ldata=/var/lib/mysql/
Installing MariaDB/MySQL system tables in '/var/lib/mysql/' ...
2016-06-30 14:50:20 139624255564032 [Note] /usr//sbin/mysqld (mysqld 10.1.14-MariaDB-1~xenial) starting as process 1375 ...
2016-06-30 14:50:20 139624255564032 [ERROR] mysqld: Can't lock aria control file '/var/lib/mysql/aria_log_control' for exclusive use, error: 11. Will retry for 30 seconds
2016-06-30 14:50:51 139624255564032 [ERROR] mysqld: Got error 'Could not get an exclusive lock; file is probably in use by another process' when trying to use aria control file '/var/lib/mysql/aria_log_control'
2016-06-30 14:50:51 139624255564032 [ERROR] Plugin 'Aria' init function returned error.
2016-06-30 14:50:51 139624255564032 [ERROR] Plugin 'Aria' registration as a STORAGE ENGINE failed.
2016-06-30 14:50:51 139624255564032 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2016-06-30 14:50:51 139624255564032 [Note] InnoDB: The InnoDB memory heap is disabled
2016-06-30 14:50:51 139624255564032 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2016-06-30 14:50:51 139624255564032 [Note] InnoDB: Memory barrier is not used
2016-06-30 14:50:51 139624255564032 [Note] InnoDB: Compressed tables use zlib 1.2.8
2016-06-30 14:50:51 139624255564032 [Note] InnoDB: Using Linux native AIO
2016-06-30 14:50:51 139624255564032 [Note] InnoDB: Using SSE crc32 instructions
2016-06-30 14:50:51 139624255564032 [Note] InnoDB: Initializing buffer pool, size = 256.0M
2016-06-30 14:50:51 139624255564032 [Note] InnoDB: Completed initialization of buffer pool
2016-06-30 14:50:51 139624255564032 [ERROR] InnoDB: Unable to lock ./ibdata1, error: 11
2016-06-30 14:50:51 139624255564032 [Note] InnoDB: Check that you do not already have another mysqld process using the same InnoDB data or log files.
2016-06-30 14:50:51 139624255564032 [Note] InnoDB: Retrying to lock the first data file
2016-06-30 14:50:52 139624255564032 [ERROR] InnoDB: Unable to lock ./ibdata1, error: 11
2016-06-30 14:50:52 139624255564032 [Note] InnoDB: Check that you do not already have another mysqld process using the same InnoDB data or log files.
2016-06-30 14:50:53 139624255564032 [ERROR] InnoDB: Unable to lock ./ibdata1, error: 11
2016-06-30 14:50:53 139624255564032 [Note] InnoDB: Check that you do not already have another mysqld process using the same InnoDB data or log files.
2016-06-30 14:50:54 139624255564032 [ERROR] InnoDB: Unable to lock ./ibdata1, error: 11
2016-06-30 14:50:54 139624255564032 [Note] InnoDB: Check that you do not already have another mysqld process using the same InnoDB data or log files.
2016-06-30 14:50:55 139624255564032 [ERROR] InnoDB: Unable to lock ./ibdata1, error: 11
2016-06-30 14:50:55 139624255564032 [Note] InnoDB: Check that you do not already have another mysqld process using the same InnoDB data or log files.
2016-06-30 14:50:56 139624255564032 [ERROR] InnoDB: Unable to lock ./ibdata1, error: 11
2016-06-30 14:50:56 139624255564032 [Note] InnoDB: Check that you do not already have another mysqld process using the same InnoDB data or log files.
2016-06-30 14:50:57 139624255564032 [ERROR] InnoDB: Unable to lock ./ibdata1, error: 11
2016-06-30 14:50:57 139624255564032 [Note] InnoDB: Check that you do not already have another mysqld process using the same InnoDB data or log files.
2016-06-30 14:50:58 139624255564032 [ERROR] InnoDB: Unable to lock ./ibdata1, error: 11
2016-06-30 14:50:58 139624255564032 [Note] InnoDB: Check that you do not already have another mysqld process using the same InnoDB data or log files.
2016-06-30 14:50:59 139624255564032 [ERROR] InnoDB: Unable to lock ./ibdata1, error: 11
2016-06-30 14:50:59 139624255564032 [Note] InnoDB: Check that you do not already have another mysqld process using the same InnoDB data or log files.
2016-06-30 14:51:00 139624255564032 [ERROR] InnoDB: Unable to lock ./ibdata1, error: 11
2016-06-30 14:51:00 139624255564032 [Note] InnoDB: Check that you do not already have another mysqld process using the same InnoDB data or log files.
2016-06-30 14:51:01 139624255564032 [ERROR] InnoDB: Unable to lock ./ibdata1, error: 11
2016-06-30 14:51:01 139624255564032 [Note] InnoDB: Check that you do not already have another mysqld process using the same InnoDB data or log files.
2016-06-30 14:51:02 139624255564032 [ERROR] InnoDB: Unable to lock ./ibdata1, error: 11
2016-06-30 14:51:02 139624255564032 [Note] InnoDB: Check that you do not already have another mysqld process using the same InnoDB data or log files.
2016-06-30 14:51:03 139624255564032 [ERROR] InnoDB: Unable to lock ./ibdata1, error: 11
2016-06-30 14:51:03 139624255564032 [Note] InnoDB: Check that you do not already have another mysqld process using the same InnoDB data or log files.
2016-06-30 14:51:04 139624255564032 [ERROR] InnoDB: Unable to lock ./ibdata1, error: 11
2016-06-30 14:51:04 139624255564032 [Note] InnoDB: Check that you do not already have another mysqld process using the same InnoDB data or log files.
2016-06-30 14:51:05 139624255564032 [ERROR] InnoDB: Unable to lock ./ibdata1, error: 11
2016-06-30 14:51:05 139624255564032 [Note] InnoDB: Check that you do not already have another mysqld process using the same InnoDB data or log files.
2016-06-30 14:51:06 139624255564032 [ERROR] InnoDB: Unable to lock ./ibdata1, error: 11
2016-06-30 14:51:06 139624255564032 [Note] InnoDB: Check that you do not already have another mysqld process using the same InnoDB data or log files.
2016-06-30 14:51:07 139624255564032 [ERROR] InnoDB: Unable to lock ./ibdata1, error: 11
2016-06-30 14:51:07 139624255564032 [Note] InnoDB: Check that you do not already have another mysqld process using the same InnoDB data or log files.
2016-06-30 14:51:08 139624255564032 [ERROR] InnoDB: Unable to lock ./ibdata1, error: 11
2016-06-30 14:51:08 139624255564032 [Note] InnoDB: Check that you do not already have another mysqld process using the same InnoDB data or log files.
2016-06-30 14:51:09 139624255564032 [ERROR] InnoDB: Unable to lock ./ibdata1, error: 11
2016-06-30 14:51:09 139624255564032 [Note] InnoDB: Check that you do not already have another mysqld process using the same InnoDB data or log files.
2016-06-30 14:51:10 139624255564032 [ERROR] InnoDB: Unable to lock ./ibdata1, error: 11
2016-06-30 14:51:10 139624255564032 [Note] InnoDB: Check that you do not already have another mysqld process using the same InnoDB data or log files.
2016-06-30 14:51:11 139624255564032 [ERROR] InnoDB: Unable to lock ./ibdata1, error: 11
2016-06-30 14:51:11 139624255564032 [Note] InnoDB: Check that you do not already have another mysqld process using the same InnoDB data or log files.
2016-06-30 14:51:12 139624255564032 [ERROR] InnoDB: Unable to lock ./ibdata1, error: 11
2016-06-30 14:51:12 139624255564032 [Note] InnoDB: Check that you do not already have another mysqld process using the same InnoDB data or log files.
2016-06-30 14:51:13 139624255564032 [ERROR] InnoDB: Unable to lock ./ibdata1, error: 11
2016-06-30 14:51:13 139624255564032 [Note] InnoDB: Check that you do not already have another mysqld process using the same InnoDB data or log files.
2016-06-30 14:51:14 139624255564032 [ERROR] InnoDB: Unable to lock ./ibdata1, error: 11
2016-06-30 14:51:14 139624255564032 [Note] InnoDB: Check that you do not already have another mysqld process using the same InnoDB data or log files.
2016-06-30 14:51:15 139624255564032 [ERROR] InnoDB: Unable to lock ./ibdata1, error: 11
2016-06-30 14:51:15 139624255564032 [Note] InnoDB: Check that you do not already have another mysqld process using the same InnoDB data or log files.
2016-06-30 14:51:16 139624255564032 [ERROR] InnoDB: Unable to lock ./ibdata1, error: 11
2016-06-30 14:51:16 139624255564032 [Note] InnoDB: Check that you do not already have another mysqld process using the same InnoDB data or log files.
2016-06-30 14:51:17 139624255564032 [ERROR] InnoDB: Unable to lock ./ibdata1, error: 11
2016-06-30 14:51:17 139624255564032 [Note] InnoDB: Check that you do not already have another mysqld process using the same InnoDB data or log files.
2016-06-30 14:51:18 139624255564032 [ERROR] InnoDB: Unable to lock ./ibdata1, error: 11
2016-06-30 14:51:18 139624255564032 [Note] InnoDB: Check that you do not already have another mysqld process using the same InnoDB data or log files.
2016-06-30 14:51:19 139624255564032 [ERROR] InnoDB: Unable to lock ./ibdata1, error: 11
2016-06-30 14:51:19 139624255564032 [Note] InnoDB: Check that you do not already have another mysqld process using the same InnoDB data or log files.
2016-06-30 14:51:20 139624255564032 [ERROR] InnoDB: Unable to lock ./ibdata1, error: 11
2016-06-30 14:51:20 139624255564032 [Note] InnoDB: Check that you do not already have another mysqld process using the same InnoDB data or log files.
2016-06-30 14:51:21 139624255564032 [ERROR] InnoDB: Unable to lock ./ibdata1, error: 11
2016-06-30 14:51:21 139624255564032 [Note] InnoDB: Check that you do not already have another mysqld process using the same InnoDB data or log files.
2016-06-30 14:51:22 139624255564032 [Note] InnoDB: Highest supported file format is Barracuda.
2016-06-30 14:51:22 139624255564032 [Note] InnoDB: 128 rollback segment(s) are active.
2016-06-30 14:51:22 139624255564032 [Note] InnoDB: Waiting for purge to start
2016-06-30 14:51:22 139624255564032 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.29-76.2 started; log sequence number 6874729
2016-06-30 14:51:22 139623489570560 [Note] InnoDB: Dumping buffer pool(s) not yet started
2016-06-30 14:51:22 139624254761728 [Warning] InnoDB: Cannot open table tmp/#sql_55f_0 from the internal data dictionary of InnoDB though the .frm file for the table exists. See http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting.html for how you can resolve the problem.
2016-06-30 14:51:22 7efcce1b6b00 InnoDB: Error: table `tmp`.`#sql_55f_0` does not exist in the InnoDB internal
InnoDB: data dictionary though MySQL is trying to drop it.
InnoDB: Have you copied the .frm file of the table to the
InnoDB: MySQL database directory from another database?
InnoDB: You can look for further help from
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting.html
ERROR: 1932 Table 'information_schema./tmp/#sql_55f_0' doesn't exist in engine
2016-06-30 14:51:22 139624255564032 [ERROR] Aborting
vagrant@homestead:~$ ps -faux | grep mysql
vagrant 1656 0.0 0.0 14512 948 pts/0 S+ 15:22 0:00 \_ grep --color=auto mysql
vagrant@homestead:~$ ps -faux | grep maria
vagrant 1659 0.0 0.0 14512 1024 pts/0 S+ 15:22 0:00 \_ grep --color=auto maria
@jlmmns Weird, it's not running at all.
What you could do is exit the vagrant box and then
vagrant destroy && vagrant up
To rebuild the box from scratch.
@renedekat Awesome! That did the trick.
I did provision mariadb: true in my Homestead.yaml file, after I had already installed the vagrant box without it.
Maybe it can't handle that properly?
If you hadn't done a vagrant reload --provision after making that change, maria probably never got installed.
I did provision mariadb: true in my Homestead.yaml file, after I had already installed the vagrant box without it.
That bit of information was missing in your initial post :) A reload --provision might have fixed that, but in this case it doesn't matter, because from what I understood from your post you wanted to reinstall Homestead (complete uninstall). Glad you got it sorted.
@renedekat @willvincent Still not completely solved, apparently...
When I re-install the vagrant box, or vagrant reload --provision, it does seem to work after that.
But when I halt at the end of the day, and the next day up, it's the same problem all over again.
I work on both a work computer and my computer at home, with the exact same setup and Homestead configuration.
I only sync my project folder with Dropbox. But that shouldn't matter.
So it seems to be either an issue with Homestead or MySQL/MariaDB, right?
Edit: Hmm, this could be related to the issue... https://github.com/laravel/homestead/pull/346
@renedekat @willvincent The merged pull #346 didn't have any effect.
The problem happens when I do:
Then after 1 minute, my mysql/mariadb stops working and the database connection will timeout.
vagrant reload --provision won't fix it.
I have to create a fresh box using vagrant destroy and vagrant up to get it working again.
And of course I can't just leave my VM running all the time.
So what do I do?
Is a vagrant suspend safe to use when shutting down my computer?
Edit: Re-installed Homestead from scratch again.
But after halt, and up, the database connection times out again after 1 minute.
I am experiencing something similar.
So, I'm not sure which is the root cause, but I updated my vagrant (1.8.4), virtualBox(5.0.24) and homestead(0.5.0) all last week. I needed to start using it all again so I figured get the latest stable builds.
Since then, closing my computer (sleep), rebooting, shutting down (without halting vagrant) all break my mysql users, including the "homestead" user. The only fix has been to destroy the box and re up, reinstall my databases and proceed.
So last week while trying to figure out the cause I came across the following. I am running Windows 10, and the "fast startup" feature was turned on just prior to these issues starting, and turning it off seemed to fixed the problem for me.
Fast forward to today, after 3 days of no issues. I ran apt-get to update the php7 install on the box and on logging back in after a vagrant reload it was broken again. So no not quite fixed. It seems turning the "fast startup" feature in Windows off has made mine more robust over all, but has not completely fixed the fact that changes to the box keep breaking database access. Or it's just a placebo effect, and things were never better, just not breaking for a couple days.
On a related note: I've backed up ALL of my mysql database files to my share folder, and replacing them when this happens. Still broken.
The main reason I'm posting here is, yours is the first issue similar to mine that I'm finding.
Finally: Destroy and up are fine, but reinstating my databases takes at best 10-15 minutes to put back, then my current seeding takes another 12 minutes to configure these databases. I'd really like to get back to a stable homestead box.
So the last answer was four months ago and this problem popped up for me today. Any fix in sight? I need to reboot Homestead to get it working again for the next minute. This is not a god development workflow.
@ddunderfelt For some weird reason, mine magically started working again how it should.
Up until last week... when I set up Homestead on my new machine. Same problem all over again.
Since I couldn't lose any time, I simply started using Valet with vendor services like Redis installed directly on my Mac.
When I get closer to releasing our product, I need to go back to Homestead again, to match the exact production environment.
But for now, development with Valet is just fine, if not better! It's a lot faster than using a Homestead virtual environment.
However, this is a major problem that needs to get addressed properly.
Started running into this issue last night after restarting a homestead environment for the first time since spinning it up a few days ago (first MariaDB project so have never used MariaDB in homestead before). This has been driving me up the wall. Essentially, on halt or machine termination, MariaDB would terminate after about a minute as described.
However, after much head beating against wall, I found this today: http://askubuntu.com/a/753280
This seems to be the golden ticket for me. So I added this to my after script:
# Fix annoying issue with MariaDB failing after about a minute and terminating
sudo apt-get -y install apparmor-utils;
sudo aa-complain /usr/sbin/mysqld;
sudo service apparmor reload;
Crossing my fingers, but everything seems to be working now.
I struggled with this for a couple weeks back then and for me a fresh install of VirtualBox, Vagrant and Homestead was the ticket. I'm not sure what in the combination of those three was the root cause of this particular issue, but I did a deep clean and removed all of them and reinstalled with what was at the time the newest versions of all three and the issues were gone. I've been running solid and updating each regularly without fail or issue since.
Just out of curiosity what versions of the three are you all running right now?
My current setup. Windows 10 w/ Virtualbox 5.1.10-112026 Vagrant 1.9.0 (1.9.1 is the latest I believe) Homestead 1.0.1
I'm running this setup on three machines right now and a couple of my staff are also using it without failures.
I had the same problem with MariaDB, I tried everything mentioned here. I solved it by completely disabling mysql in apparmor:
ln -s /etc/apparmor.d/usr.sbin.mysqld /etc/apparmor.d/disable/
and a restart of homestead did the trick for me.
All thanks go to plutocrat on askubuntu: https://askubuntu.com/questions/750604/why-does-mariadb-keep-dying-how-do-i-stop-it
Please or to participate in this conversation.