0

I was happily working away on a ddev project and I brought it up today and it says "db service stopped" and it doesn't seem to be fixable. ddev also said "db service health check timed out"

db service stopped

rfay
  • 9,963
  • 1
  • 47
  • 89

2 Answers2

0

On Docker For Mac (and I think on Docker for Windows) docker does not give containers a chance to gracefully exit when it's shutting down. So the MariaDB server in the database container doesn't get a chance to clean up, and nontrivial databases are left broken for the next startup (it doesn't seem to harm tiny databases). So if you're upgrading docker, shutting down your host computer, or just exiting docker, you'd be wise to first do a ddev stop or a ddev remove. (Note that a simple ddev remove does not throw away your db, it will be there for you when you start again.)

Also note that in releases before ddev v0.17.0, the ddev remove command itself had this problem: It could corrupt the db by not allowing enough time for the db container to clean up before destroying it.

I don't think this affects Linux users, and am not sure about Windows.

TLDR;

  • Make sure you're using at least v1.0.0 of ddev (and your containers reflect that). This behavior was improved quite a lot in v1.0.0.
  • Delete an existing corrupted database with ddev remove --remove-data (and after ddev start, re-import db or do install again)
  • Use the current version of ddev, and follow the upgrade instructions, which currently require deleting docker-compose.yaml and editing your config.yaml file on each project.
  • Avoid letting docker upgrade or exit, and avoid rebooting the host without stopping or ddev remove-ing projects. The open issue for this is https://github.com/drud/ddev/issues/748 but it really has to be fixed in docker-for-mac, docker-for-windows.

A second way for this to happen: Custom mysql configuration in the project. Before debugging, please remove any configuration in .ddev/mysql in case that's the cause of your problem, then ddev restart.

If your database is corrupted, you may be able to recover by adding a file named .ddev/mysql/recovery.cnf to your project and ddev start:

[mysqld]
innodb_force_recovery = 1

After recovery, remove the the file .ddev/mysql/recovery.cnf Your database is not guaranteed to be undamaged, even if it comes up OK.

[Edit 2018-05-16]: A third reason is inadequate docker resources. If you're running a few projects or have other things going on with docker, you'll want to raise the available memory from the default 2GB.

[Edit 2018-06-27]: Added instructions on recovery possibility.

[Edit 2018-08-02]: Mentioned that v1.0.0 of ddev improved this quite a lot.

rfay
  • 9,963
  • 1
  • 47
  • 89
  • Updated the answer reminding people to remove custom mysql config when debugging this. – rfay May 04 '18 at 20:58
0

I often need to close & open Docker when switching projects, and I'm not likely to be able to navigate to each of the 60+ sites I'm managing to ddev stop them all before quitting the Docker app.

Would it be possible to have a ddev stop all or similar command that would be suitable for stopping all ddev instances before quitting Docker?

jenlampton
  • 315
  • 2
  • 7
  • First, I don't recommend having more than 4-5 projects running at a time due to docker resource problems. Second, `ddev list` will show you the projects that are running, you only need to access them, and you can access them by name. So `ddev rm proj1; ddev rm proj2; ddev rm proj3` will work (even though I want the ddev rm all you suggest as well) We definitely want all commands for which it's appropriate to take multiple project names or an "all", you might want to make a feature request in https://github.com/drud/ddev/issues/new/choose though. – rfay Jun 28 '18 at 13:38
  • Could you say why you have to close and open docker when switching projects? – rfay Jun 28 '18 at 13:41
  • Recent versions of ddev have `ddev rm -a`, which I use all the time for things like this. Highly recommended, and a great way to shut down all your sites. (No databases are harmed.) – rfay Nov 18 '18 at 00:08