Mutagen daemon fails to start if MUTAGEN_DATA_DIRECTORY is too long

[chrispsplash]

Basically, if MUTAGEN_DATA_DIRECTORY is very long then the mutagen daemon won't start. This is a problem for some tools (like garden.io) which create data dirs for each project being synched.

Error example

mutagen sync create --name example-sync-issue /tmp/whatever/path docker://root@example-mutagen-issue/tmp/sync
d90d1034a67d6d65a019296c2616d89e31f5e51bf8d6775e448a2238e2c069cc
Attempting to start Mutagen daemon...
Error: unable to connect to daemon: connection timed out (is the daemon running?)

The version of Mutagen that you're using

❯ mutagen version
0.17.1

The platform(s) that you're using

• Apple MacBook Pro 13-inch, 2020, Four Thunderbolt 3 ports
• x86-64
• macOS Ventura 13.2.1 (22D68)

Reproduction steps

1. Create a very very long dir name
2. Set MUTAGEN_DATA_DIRECTORY to this dir
3. Run an arbitrary docker container
4. Start a sync

Example script

mkdir -p /tmp/Extremely/Long/path-with/some-hyphens/and/whatnot/example-bonsai-sync-issue/.garden/mutagen
export MUTAGEN_DATA_DIRECTORY=/tmp/Extremely/Long/path-with/some-hyphens/and/whatnot/example-bonsai-sync-issue/.garden/mutagen
docker run -it -d --entrypoint=sh --name example-mutagen-issue bitnami/aws-cli:2.11.15
mutagen sync create --name example-sync-issue /tmp/whatever/path docker://root@example-mutagen-issue/tmp/sync

[xenoscopic]

Thanks for digging into that further. The daemon is probably seeing ENAMETOOLONG when it attempts to bind() and is then just terminating without surfacing that error.

I'm a little surprised the same error isn't showing up in the connect() operation from the CLI. I'll have to dig into why the timeout is taking priority in the error reporting.

For now (and in general) the only thing I can think of would be to use a shorter path, but the CLI and daemon should do a better job of surfacing those errors.

Do you know the length threshold at which the name ticks over into being too long for a Unix Domain Socket?

[xenoscopic]

It looks like the exact length limitations were determined here.

One workaround I could imagine is what's done with the Windows Named Pipe transport. In that case, we just use the .sock file within the daemon directory to record the name of the allocated named pipe. We could do something similar here, i.e. allocating a random socket in (e.g.) /tmp that won't exceed the length limit and then just storing its path in the daemon directory.

[chrispsplash]

max length for domain socket name length

I see two issues (one for garden-cli and one for rancher-desktop) which put the max length for unix domain socket name at 104 (for MacOS)

workaround

confirmed! moving the project, thus the mutagen data dir, to a shorter path does work. 👌