Daemon socket should be in $XDG_RUNTIME_DIR

[heftig]

The canonical location for user service sockets (and other runtime temporary files) on systemd systems is $XDG_RUNTIME_DIR (typically /run/user/$UID). When this variable is available, Atuin should locate its daemon socket at $XDG_RUNTIME_DIR/atuin/atuin.sock by default.

[Flowdalic]

I run into the same issue when preparing atuin daemon support on Gentoo.

When this variable is available, Atuin should locate its daemon socket at $XDG_RUNTIME_DIR/atuin/atuin.sock by default.

Not only when this variable (XDG_RUNTIME_DIR) is available. Even in the absence of XDG_RUNTIME_DIR from the processes' environment, atuin should default to that. The "XDG Base Directory Specification" is states that

If $XDG_RUNTIME_DIR is not set applications should fall back to a replacement directory with similar capabilities and print a warning message. Applications should use this directory for communication and synchronization purposes and should not place larger files in it, since it might reside in runtime memory and cannot necessarily be swapped out to disk.

^{Source: https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html#variables}

So atuin's default for socket_path should be, in bash variable default-value notation, ${XDG_RUNTIME_DIR:-/run/user/${UID}}/atuin.socket.

[akinomyoga]

When it falls back to /run/user/$UID, one should check if that directory exists and has the correct owner and permission. Then, one can use that directory.

If the directory doesn't exist, one can next attempt to create a temporary directory in /tmp using mkdtemp(3), but special care would be needed to share the directory with the other calls of Atuin. Another possibility is to manually create a directory in /tmp, but it has pitfalls that may allow attackers to intercept, so one needs to be careful doing it.

Another thing to care is a known bug of WSL. In WSL systems, one should avoid using /run/user/... (even when XDG_RUNTIME_DIR specifies /run/usr/...). These problems started to happen around the last September, but I don't see any movements to solve the issue in WSL.

• WSLg's runtime-dir has always owner 1000 resulting in inaccessable runtime dir for default user microsoft/WSL#9689
• /run/user/1000 owner become root when pre mount a vhdx disk before start the wsl system microsoft/WSL#10473
• systemd_249.11-0ubuntu3.10 seems to break user sessions on WSL2 microsoft/WSL#10496
• mkdir /run/user/1000/: permission denied after WSL 2.0.0 microsoft/WSL#10498
• WSL 2.0.1: systemd-logind logs session out after few minutes, purges /run/user/{uid} microsoft/WSL#10552

[ellie]

When it falls back to /run/user/$UID, one should check if that directory exists and has the correct owner and permission. Then, one can use that directory.

Due to this additional complication in following that part of the spec, my PR doesn't fallback to it. It's also not theoretical, as we checked Alpine and it does not have this path.

If the var exists, we use it, and if it doesn't, we don't. The var is automatically set by systemd, and points to a directory that has been correctly setup. Creating and managing such a dir is very out of scope for Atuin.

Afaik we have no way of detecting WSL, and if that becomes an issue users can specify a different directory. I'm afraid "just follow XDG" is never as easy as it sounds.