Critical global configuration misbehavior: Accidental switching between ~/.ddev and ~/.config/ddev

[rfay]

Expected Behavior

The default directory should be ~/.ddev in the absence of XDG_CONFIG_HOME

On WSL2/Linux:

With mutagen enabled in the project,

If I remove all config, rm -r ~/.ddev ~/.config/ddev and then ddev start

• Global config is created in ~/.ddev
• However, an empty ~/.config/ddev is also created

If I then ddev stop

• The various things in ~/.config/ddev are populated
• ~/.config/ddev becomes the global config dir

[stasadev]

I can't reproduce it on WSL2/Linux.

Tried it with tb-wsl-12 and Arch-based Linux.

The default directory should be ~/.ddev in the absence of XDG_CONFIG_BASE

It's XDG_CONFIG_HOME, maybe you mixed up the config?

---

Or there is something wrong with os.Stat(linuxDir), and it doesn't return an error if the dir doesn't exist:

ddev/pkg/globalconfig/global_config.go

Lines 606 to 616 in 5b0e640

	// If Linux and ~/.config/ddev exists, use it,
	// we don't create this directory.
	if runtime.GOOS == "linux" {
	userConfigDir, err := os.UserConfigDir()
	if err == nil {
	linuxDir := filepath.Join(userConfigDir, "ddev")
	if _, err := os.Stat(linuxDir); err == nil {
	return linuxDir
	}
	}
	}

[rfay]

No, there were no XDG variables involved here. But this was with mutagen enabled. I'll continue chasing this and the followup problem with mutagen deleting all files in project.

[rfay]

What's going on here during certain situations where the MUTAGEN_DATA_DIRECTORY is moved from ~/.ddev-mutagen-data-directory to ~/.ddev/.mdd or ~/.config/ddev/.mdd is that there may be a mutagen instance running. If there is, then removing the previous MUTAGEN_DATA_DIRECTORY (and its parent) will not stop the mutagen process that is using it. So ~/.ddev for example will just get recreated by the running mutagen daemon.

ddev poweroff does not yet stop mutagen instances that it does not know about. So a newly upgraded ddev with current HEAD using ~/.ddev/.mdd or ~/.config/ddev/.mdd) doesn't stop the running mutagen daemon configured with MUTAGEN_DATA_DIRECTORY=~/.ddev-mutagen-data-directory.

I think we can mostly fix this by making sure that we stop mutagen sessions that may be running with a different MUTAGEN_DATA_DIRECTORY. This can be the case when we're moving our home using XDG_CONFIG_HOME, or it can be the case when moving to or from ~/.ddev or when changing the mutagen data directory from ~/.ddev-mutagen-data-directory to ~/.ddev/.mdd.

The most catastrophic demonstration of this, which I've succeeded in reproducing a few times but not predictably, is where mutagen is running (with old session storage location) and a new version of DDEV is started. The new version finds that there isn't a mutagen session that matches, so it deletes and recreates the docker volume (which the other mutagen session is using), and then the other mutagen session copies the (empty) volume into the host filesystem. We do not want this to happen!

[rfay]

I asked this of @xenoscopic in Mutagen Slack:

Today's weird migration scenario... Because of the "too long mutagen data dir" problem, and for other reasons, the mutagen dir is moving from ~/.ddev-mutagen-data-directory to ~/.ddev/.mdd or ~/.config/ddev/.mdd.

There is a scenario where there's already a mutagen sync running, and the updated DDEV doesn't have a way to know that, because it has the new configuration.

That scenario can result in the new DDEV recreating the paired docker volume (and thinking it's deleting the paired mutagen session). Unfortunately, the existing mutagen session, which hasn't been properly paused or terminated because it has a different working directory, can then sync the empty volume to the host. This is hard to recreate, but I've done it a number of times. It seems to be timing-related.

Of course this is a rarity, and can be avoided by user action (ddev poweroff or killall mutagen before doing the upgrade). But it's amazingly catastrophic and needs to be prevented.

The only fundamental approach I've come up with is to look for sessions using a few MUTAGEN_DATA_DIRECTORY values and stop them if found. Actually, if we find any sessions we can terminate all if the session is not related to our MUTAGEN_DATA_DIRECTORY.

Just running this by you to see if you have any extra ideas. I'll copy this into the issue and mention you there also. Thanks!

[xenoscopic]

Hey @rfay, I'd probably add a list of legacy Mutagen data directory paths to DDEV that it iterates through at startup and (if a particular legacy directory exists) does a MUTAGEN_DATA_DIRECTORY=<legacy-path> mutagen daemon stop, and then removes that directory (or potentially relocates it to the new location after the daemon is stopped, with some order of preference in the case of multiple legacy directories). If the legacy path is too long, one could also chdir() to the directory and do MUTAGEN_DATA_DIRECTORY=. mutagen daemon stop.

[rfay]

Thanks @xenoscopic - I'm essentially doing that strategy in https://github.com/ddev/ddev/pull/6239/files#diff-aea6a89b795b57caf90baa273b3363cd603dd42f110e773c7b2a245fbdd4d61eR112-R130

The difference is I was doing a mutagen sync pause -a rather than daemon stop. If you think daemon stop is better I'll do that. The big advantage of mutagen daemon stop is it won't accidentally start the mutagen daemon in order to pause the session :)