Closed dixhuit closed 9 years ago
Today I was working with Vlad 1.1.1 and I can confirm that bug. How to reproduce:
drush sql-cli < dump.sql
I've also noticed that when MySQL is running, the D7 site installed in that VM is reeeally slow (this might be isolated to that particular project though).
I had trouble getting the MySQL role working in the run up to 1.1.1. Most of the trouble was around starting or restarting the server. Restarting the box always worked when done on the server itself though.
I ended up swapping out the service task for a command task that just runs 'service mysql restart'. I'm not sure if this is a Vlad specific bug or an Ansible bug. I just need to isolate the issue really.
There is another call to a service task within the MySQL role that needs swapping out that should help with this. I think.
Just pushed a bit of a fix for this, could you check to see that everything is ok? If so I'll launch 1.1.2 tomorrow.
Just tested latest dev and I get the same error running drush sql-sync
.
I think this is fixed in the current version of dev, I will be tagging a new release this weekend which will include this fix.
Closing as this appears to be fixed in current master.
Vlad 1.1.1
Steps to recreate:
drush si
&drush sql-sync
so far)Workaround for now:
If you then restart MySQL things will run as they should:
Subsequent halts, ups & reloads don't seem to require this workaround.Scratch that, I'm having to restart MyQSL every so often.Vagrant 1.7.2 ansible 1.9.1 configured module search path = None vagrant-cachier (1.2.0) vagrant-hostsupdater (0.0.11) vagrant-share (1.1.4, system) vagrant-triggers (0.5.0)