drush
drush copied to clipboard
drush-ops
Drush 8 uses .my.cnf data instead of settings.php and has no way to override this behavior
Describe the bug See these threads for full details This is not a good enough answer. Scripts on the server setups I have already use .my.cnf for doing a lot of tasks. Drupal's database is on another machine. Drush needs a way to disable this functionality and it's bad it was ever added. It's been very disruptive see: https://www.drupal.org/project/drush/issues/2852233 #2750 #2183
To Reproduce Install drush and have a .my.cnf file. If the drupal site you're working on has it's database on another machine or uses a different user that doesn't have permissions it won't work at all and you get non explanatory error messages about bootstrap failures.
Expected behavior That it would use the settings that drupal uses to connect to the database not the settings all the scripts on my servers use to connect to the local database.
Actual behavior It used the .my.cnf data instead of connecting to the drupal database.
Workaround The work around is unacceptable it requires me to delete .my.cnf thus breaking a ton of scripts that rely on it.
System Configuration
| Q | A |
|---|---|
| Drush version? | 8.3.5 |
| Drupal version? | 7.72 |
| PHP version | 7.2.9 |
| OS? | CentOS Linux release 7.6.1810 (Core) |
Additional information Drush needs a flag to FAITHFULLY recreate the same connection paramaters that drupal uses this should be obvious you want drush to mimic the behavior of drupal in this, at least as an option.
I had 3 hours of debugging last night in which removing .my.cnf fixed the issue, I am using drush 8.3.5
output using debug shows it is using --defaults-extra-file output below.
Executing: mysql --defaults-extra-file=/tmp/drush_Og7Wto --database=dbname --host=111.222.333.444 --silent < /tmp/drush_t2PcTx
moving my .my.cnf file to .my.cnf.disabled fixed all of my issues with drush but created a ton of problems for scripts on my server.
From that issue "Some people depend on current behavior so back porting is tricksy". The change cannot be safely backported to Drush 8.
I think we could consider a backport of #2387 to the 8.x branch if it was opt-in, e.g. if a Drush config option could be set to control whether defaults-extra-file or default-file is used.
Yes even if you have a flag. It should have been a flag to use .my.cnf's in the first place, but since others depend on it as is we should do it as a flag to skip .my.cnf and it should be given as something to try when database failure occurs, along with making sure the person has a mysql client installed and I think it would be much more user friendly in these cases as in my debugging I found those were the most common reasons for getting the bootstrap failure messages.