Mysql not started on boot

[cbrunnkvist]

According to the tutorial, provisioning should take care of everything so you should be good to go after the initial vagrant up. However, in the current master mysqld does not come up automatically.

I'm currently unaware of whether there are some issues with mysqld+upstart in Precise, but sticking an update-rc.d mysql defaults somewhere around provision.sh:328 should fix this.

(In case it is a conscious design decision I don't see it documented anywhere;))

[jeremyfelt]

Thanks for the report @cbrunnkvist!

We do have a custom init script that should take care of MySQL after vagrant halt, but I'm not sure how it handles the initial boot. I do think things will get easier once we stop using persistent databases as we won't be racing to mount/start services. Fingers crossed for #213.

I'll do some testing in a bit to duplicate the issue and toss that line in.

[torrottum]

+1, have had the same problem more than a couple of times. Have to SSH in and start MySQL manually

[jeremyfelt]

I just checked out a fresh copy of master and did an initial vagrant up. All services are a go for me.

I also did a vagrant halt and vagrant up after the initial boot and services are working properly there.

Is there a chance that something failed during the initial provisioning? There may be an error we can detect.

[cbrunnkvist]

"Works for me" vs. "Doesn't work for me". Strange. Yeah it could be some case where something fails, perhaps due to a timeout or ephemeral DNS error, during initial apt-get & dpkg configure, and that's why it doesn't start automatically.

[jeremychurch]

I think I'm having the same issue. Yesterday I downloaded Vagrant, VirtualBox and master, and got everything running (btw, love it). Today it seems MySQL isn't running. If I vagrant halt and then vagrant up it doesn't spin up unless I run vagrant provision.

Though I didn't think to start MySQL manually as @toringerottum suggested, but seems to be the same issue.

[kraftner]

Same here. Manually starting MySQL works though.

[cfoellmann]

I am having this problem all the time. No exceptions.
I suspect some issues with the whole setup (VirtualBox + Vagrant) on Windows?

[obenland]

I just had the database problem too. Provisioning did it for me.

[jeremyfelt]

@kraftner @cfoellmann @obenland (and anyone else having this trouble)

• Does MySQL fail to start after halting the VM with vagrant halt and then bringing it back up with vagrant up? Or is this vagrant up from scratch or after vagrant destroy?
• Every time, or sporadically?
• What OS / VirtualBox version / Vagrant version?
• How long does vagrant up take after a vagrant halt?

This sounds so much like it used to be before we got the right init scripts in the for MySQL. The entire thing is hacky though. I'm guessing that some of this goes away once we stop worrying about persistent database data, but it would still be cool to figure out so that nobody has to run vagrant provision each time. :)

[obenland]

In my case I never shut the VM down. After restarting my computer at some point and vagrant up, I ran into the error.

[kraftner]

• worked on initial vagrant up, doesn't work after vagrant halt/up, works after vagrant destroy/up, doesn't work again after vagrant halt/up
• tried it 4 times, never works after vagrant halt/up
• Ubuntu 13.10 / VirtualBox 4.2.16_Ubuntu 86992 / Vagrant 1.4.3
• up takes about 15 seconds after vagrant halt (brand new haswell cpu + ssd)

[joshuathayer]

Hey guys- I stumbled across this page while looking for answers for a similar problem: MySQL was not coming up automatically after vagrant up while booting a guest 12.04 box.

In my case, MySQL is configured to listen on a particular IP on the VM. It turned out that MySQL was trying to start before the network came up. I changed my upstart configuration to wait until after the network was configured- see [1].

So, changing the "start on" line in /etc/init/mysql.conf to

start on filesystem and net-device-up IFACE!=lo

worked well.

I'm not sure if your case is the same, so YMMV. Good luck!

[1] http://askubuntu.com/questions/62812/why-isnt-my-upstart-service-starting-on-system-boot

[andrezrv]

I've been silently following this issue and trying to track down the problem for a couple of weeks now, since it happens in all of my VMs. I use Windows 7 (64 bits) as host, so this may not be useful for Linux users.

I initially went the upstart way, thinking that something might be wrong there, but none of the things I tried worked. Just a few minutes ago, I started one of my VMs from the Virtualbox Administrator, which shows some information that is not visible when you start via Vagrant. This was what showed up for me:

Something was failing indeed, so I went to the /etc/init/vvv-start.conf file (the script that should start MySQL) to see what was wrong there. I didn't see anything weird in the code, but if I executed the file manually, a "unexpected end of file" error would appear. That could only mean that the file was using incorrect line endings (well, not only, but it's a typical error). Sublime Text 3 said that my local ./config/init/vvv-start.conf file (the file that is copied to /etc/init/vvv-start.conf) was in ASCII format (yeah, WTF), and the line endings were Windows'. I changed it all to UTF-8 and Unix, halted the VM, then vagrant up and vagrant ssh. Once in there, I ran sudo cp /srv/config/init/vvv-start.conf /etc/init/vvv-start.conf, halt and up again. When the VM started and I logged in, I could finally see mysql start/running.

tl;dr; version: If you're using Windows, make sure your ./config/init/vvv-start.conf file is using Unix line endings.

[jeremyfelt]

Great hunting @andrezrv! I just modified .gitattributes to force unix line endings on conf files as well. This could help the issue.

[jonathan-dejong]

I'm having this problem as well.

Does MySQL fail to start after halting the VM with vagrant halt and then bringing it back up with vagrant up? Or is this vagrant up from scratch or after vagrant destroy?
Happens on every vagrant up, is resolved by vagrant provision or manual startup of mysql

Every time, or sporadically?
Every time so far (like 6 times)

What OS / VirtualBox version / Vagrant version?
Latest from virtualbox/vagrant, OS X 10.9.2

How long does vagrant up take after a vagrant halt?
Not long, 10 seconds maybe.

I checked my file endings etc. like andrezvr has posted above but they're already set to Unix and UTF-8.

[andrezrv]

@jonathan-dejong: You may want to run manually your /etc/init/vvv-start.conf file (from inside the VM) and see if that triggers some syntax error. It is expected to fail saying description: command not found and start: Unknown job: on, but it will give some input in case something is wrong within the file.

On the other hand, since I'm working on Windows, I'm really not sure if another solution is needed for OS X systems.

[iandunn]

I'm experiencing this too.

Does MySQL fail to start after halting the VM with vagrant halt and then bringing it back up with vagrant up? Or is this vagrant up from scratch or after vagrant destroy?

It fails after every halt/up. It works with vagrant up --provision, though.

Every time, or sporadically?

Every time.

What OS / VirtualBox version / Vagrant version?

OS X 10.9.2
VirtualBox 4.3.8 r92456
Vagrant 1.5.1

How long does vagrant up take after a vagrant halt?

~25 seconds. About 10 of those are sitting idle after SSH auth method: private key:

default: SSH auth method: private key default: Error: Connection timeout. Retrying... ==> default: Machine booted and ready!

With VAGRANT_LOG=DEBUG, I see several dozen of these:

DEBUG subprocess: Waiting for process to exit. Remaining to timeout: 32000

I think that's an unrelated issue, but I though I'd mention it in case everyone else is seeing it too.

start on filesystem and net-device-up IFACE!=lo didn't help.

Some notables from various logs:

[ 7.861005] init: mysql main process (1696) terminated with status 1
[ 7.861032] init: mysql respawning too fast, stopped
'[ 286.574729] Pid: 2134, comm: mysqld Tainted: G O 3.2.0-23-generic-pae #36-Ubuntu'
initctl: Unknown job: S20mysql

Expanded logs are at http://pastebin.com/MNNhzyxv.

[jeremyfelt]

This finally happened for me just now. 👍

[paulgibbs]

Just saw this, too.

[jfarsen]

Happens to me, but only in an employee's home, not our main office. weird. Will have the employee bring in the machine tomorrow and determine if local LAN can have an incidence or not, ... but it really shouldn't ...

Edit : problems seems to come from employee's home LAN, as it's working fine in our office.

[weskoop]

Happening to me now, I triggered it with an "sudo apt-get update && sudo apt-get upgrade"

(provisioning brings it up)

[tony-wips]

you can save yourself from a lengthy provisioning by simply SSH-ing into guest and issuing a 'sudo service mysql start'. It'll work (guess we're all in the same issue)

[shaneholloman]

Same issue here after vagrant halt on fresh:
Mavericks 10.9.2
Vagrant 1.5.2
VirtulalBox 4.3.10

vagrant up --provision not ideal solution but fixes

[jeremyfelt]

Making progress today in the VVV database branch on PR #322. By removing our reliance on a persistent database connection, we can avoid these timing issues.

vagrant ssh -c "sudo service mysql start" is probably the least annoying way of starting MySQL from the host in the meantime and should hopefully avoid the need to do a full re-provision.

[jonathan-dejong]

Great work Jeremy!
Looking forward to this merge :) 👍

[shaneholloman]

vagrant ssh -c "sudo service mysql start @jeremyfelt very helpful!

[obstschale]

Thx! That is very helpful 👍

[plicjo]

Jeremy, that was the money solution!

[jeremyfelt]

Ok. As of today, #322 has been merged into master and MySQL data will no longer be mapped locally. This clears up the issue where MySQL is not available after a halt, as we no longer need to be hacky about detecting when the drive is mapped before starting the service.

A few things about the latest master:

• Your best bet is a full destroy and up to reprovision with the new Ubuntu box.
• Delete everything except for readme.txt in the /database/data/ directory if you don't want persistent databases. Backup your data first if you want it.
• Install the vagrant-triggers plugin for backups of the database to be created automatically on every halt and destroy.

[jonathan-dejong]

Hi!

Great news Jeremy.
To clarify for someone with less knowledge:

1. Do I have to delete everything in database/data for this to be fixed properly? Since I have a few sites running and rather not have to reinstall their DBs
2. Is the vagrant-triggers plugin necessery? I found that in order to install it I require nokogiri, in order to install nokogiri I require honeybrew (or similar) as well as some other libs like libiconv and libxml2 etc. Basically it's a pain in the ass just to get vagrant-triggers :)

EDIT:
So it seemed nokogiri was due to a bug in vagrant > nokogiri which is now fixed. So now I have that installed and you can ignore my second question.. However my first remains and I'd be grateful for anyone to chime in! :)

[aubreypwd]

I am still experiencing this. I did a git pull to master, destroyed my box, update Vagrant, re-vagrant up'd and as soon as I did a halt and up mysql will not connect. A up --provision will restore the mysql service and it works until the next halt.

https://www.dropbox.com/s/einh8ha0rs7u7zb/Screenshot%202014-05-16%2011.55.16.png
https://www.dropbox.com/s/fz02mf8f5a80cxg/Screenshot%202014-05-16%2011.55.39.png

Like the guy above I'm not sure about:

Delete everything except for readme.txt in the /database/data/ directory if you don't want persistent databases. Backup your data first if you want it.

[tnorthcutt]

@jeremyfelt same question for me as @jonathan-dejong and @aubreypwd regarding deleting everything in /database/data/. Is there a suggested path to upgrade to the new functionality, without nuking existing sites?

[jeremyfelt]

This is tough. I do want to find a way.

Theoretically with a grain of salt in the current form.... :)

1. vagrant destroy
   • This deletes the VM and sets things up to be re-provisioned in Ubuntu 14.04
2. Pull latest VVV version
3. Install vagrant-triggers plugin.
4. vagrant up
   • Because your existing mapped MySQL data continues to live in database/data/, your databases will persist in the new VVV.
5. vagrant destroy
   • The vagrant-triggers plugin will run the new script to backup the existing databases.
6. Delete all of your files from database/data/ OR rename the one file we check for in provisioning.
7. vagrant up
   • We'll now import the backed up SQL files into the fresh installation of MySQL that is not mapped to your local machine.

Phew...

More testing is definitely required. I'd be very careful at the moment with data you don't want to lose. It would be worth using phpMyAdmin to backup everything if you're more familiar with that.

[jonathan-dejong]

That is a handful!

I'm most likely going to take a backup of each database like you say… Probably backup the entire VVV folder as well. Fortunately I've only got 3-4 projects running in vagrant so far :)

Can't say when I'll give this a try but I'll come back with a report afterwards.

[jonathan-dejong]

So I've done some testing on this..
I basically followed your instructions above with the difference that I already had wp-triggers installed.

Deleted all files from database/data however I found this readme inside database/backups:
SQL files created with mysqldump should be stored in database/backups so that they are automatically imported as the Vagrant VM boots up.

For this to work properly, databases should be created in your database/init-custom.sql file as explained in database/init-custom.sql.sample.

Once these original files have been imported, they will exist in database/data as the actual mysql data directory and will not need to be reimported on the next vagrant up.

Is this something I have to do manually first? And if so, do I have to do this for each new site?
Because as I did this I recieved these errors during the last vagrant up:

==> default: mysql start/running, process 20962
==> default:
==> default: No custom MySQL scripting found in database/init-custom.sql, skipping...
==> default: Initial MySQL prep...
==> default: Start MySQL Database Import
==> default: ERROR
==> default: 1049 (42000)
==> default: at line 1
==> default: : Unknown database 'bankofinans_db'
==> default: * Error - Create bankofinans_db database via init-custom.sql before attempting import
==> default: ERROR
==> default: 1049 (42000)
==> default: at line 1
==> default: : Unknown database 'barentsgames'
==> default: * Error - Create barentsgames database via init-custom.sql before attempting import
==> default: ERROR
==> default: 1049 (42000)
==> default: at line 1
==> default: : Unknown database 'jigoshop_db'
==> default: * Error - Create jigoshop_db database via init-custom.sql before attempting import
==> default: ERROR
==> default: 1049 (42000)
==> default: at line 1
==> default: : Unknown database 'tjallden'
==> default: * Error - Create tjallden database via init-custom.sql before attempting import
==> default: mysql -u root -proot wordpress_default < wordpress_default.sql
==> default: * Import of wordpress_default successful
==> default: mysql -u root -proot wordpress_develop < wordpress_develop.sql
==> default: * Import of wordpress_develop successful
==> default: mysql -u root -proot wordpress_trunk < wordpress_trunk.sql
==> default: * Import of wordpress_trunk successful

You also write that it's possible to "OR rename the one file we check for in provisioning." To which file are you referring?

[jeremyfelt]

Haha, you caught me being lazy. :)

If database/data/mysql_upgrade_info exists, we mount the database drive. An easy way to flip back and forth is to rename that to mysql_upgrade_info.old or something.

These databases do need to be defined in init-custom.sql for them to be added automatically during provisioning. We may need to look into how this works with external auto site setups.

[jonathan-dejong]

So a quick update for anyone finding this thread.
This workflow: #287 (comment)
works for me with the addition that I've added all my own sites databases to the database/init-custom.sql

Could also be noted that I didnt do it in the exact same way since I already had wp-triggers installed. But the basics are the same.. destroy, pull från official repo, up, destroy, delete /data, up again and you're done!

Another thing, I had to reboot my computer before running the last vagrant up because of constant timedout issues with SSH.

[aubreypwd]

@jeremyfelt's input above helped me resolve my situation. mysql starting on it's own and stays up regardless of state.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.