Unable to attach to sessions over SSH

[abitrolly]

2. Issues with the Zellij UI / behavior / crash

Issue description

Currently Zellij session discovery need $XDG_RUNTIME_DIR, which is set by systemd, and may not be set when connecting over SSH #3700

Minimal reproduction

1. Open local session, run some commands
2. Connect from remote machine over SSH
3. Run zellij attach to local session

See no content from previous commands in attached tab.

Other relevant information

[tgulacsi]

Just set XDG_RUNTIME_DIR (in .profile, .bash_profile, .bashrc, .fishrc, .zshrc - as your shell wishes).

[abitrolly]

@tgulacsi I am not proficient in systemd sources to replicate the logic needed to handle XDG_RUNTIME_DIR correctly.

[tgulacsi]

Just.check its value in a proper login session, and replicate that (usually /run/user/$(id -un) works). Ekkor: 2024. november 3. 10:07:21 UTC, Anatoli Babenia ***@***.***> írta:

@tgulacsi I am not proficient in `systemd` sources to replicate the logic needed to handle `XDG_RUNTIME_DIR` correctly. -- Reply to this email directly or view it on GitHub: #3708 (comment) You are receiving this because you were mentioned. Message ID: ***@***.***>

Tamás Gulácsi

[abitrolly]

@tgulacsi why Zellij can not do this itself?

[tgulacsi]

It's not that easy: the spec says:

$XDG_RUNTIME_DIR defines the base directory relative to which user-specific non-essential runtime files and other file objects (such as sockets, named pipes, ...) should be stored. The directory MUST be owned by the user, and they MUST be the only one having read and write access to it. Its Unix access mode MUST be 0700.

The lifetime of the directory MUST be bound to the user being logged in. It MUST be created when the user first logs in and if the user fully logs out the directory MUST be removed. If the user logs in more than once they should get pointed to the same directory, and it is mandatory that the directory continues to exist from their first login to their last logout on the system, and not removed in between. Files in the directory MUST not survive reboot or a full logout/login cycle.

The directory MUST be on a local file system and not shared with any other system. The directory MUST by fully-featured by the standards of the operating system. More specifically, on Unix-like operating systems AF_UNIX sockets, symbolic links, hard links, proper permissions, file locking, sparse files, memory mapping, file change notifications, a reliable hard link count must be supported, and no restrictions on the file name character set should be imposed. Files in this directory MAY be subjected to periodic clean-up. To ensure that your files are not removed, they should have their access time timestamp modified at least once every 6 hours of monotonic time or the 'sticky' bit should be set on the file.

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.

So MAYBE zellij could use ${XDG_RUNTIME_DIR:-${XDG_CACHE_HOME:-$HOME/.cache}}, and print a warning, but that's risky (that .cache may or may not be safe enough). Setting XDG_RUNTIME_DIR in your shell is way more explicit and safe.

[lgarron]

I'm also running into this with zellij 0.41.2.

• Both computers are macOS.
• The SSH session is properly logged into the same user on the other machine, with the same (fish) shell configuration loaded.

I've even tried setting $XDG_RUNTIME_DIR — that did nothing.

Somehow, zellij on the same system seems to keep completely separate sessions despite all this, and I can't figure out anything in the environment that would cause this.

[lgarron]

Ah, copying my comment from #3700 (reply in thread)

Oh! I tried pkill zellij on a whim, and that worked. Both the issue and the fix are… very not obvious. Is there documentation on why I would ever expect the default behaviour in the first place?

I feel like:

• Connecting over SSH is a use case zellij is very suited for.
• Even as a die-hard XDG spec user and advocate, I didn't have $XDG_RUNTIME_DIR set.

I also have yet to find information about this on the FAQ or anywhere else in the docs. 😔

[lgarron]

I tried pkill zellij on a whim, and that worked.

Hmm, it seems the issue returns almost immediately. When I create a new session locally, then that session is not visible over SSH. 😕

I'd definitely appreciate an explanation of the mental model I should have for how this is supposed to work.

[lgarron]

Okay, here's the situation.

On the server (not over SSH):

echo $XDG_RUNTIME_DIR
zellij attach --create foo1337

From a client (over SSH):

ssh [server-name]
# Over SSH:
  echo $XDG_RUNTIME_DIR
  zellij attach --create foo1337

In both cases, $XDG_RUNTIME_DIR prints the exact same path. (I've tried this with both /Users/lgarron/.cache/xdg_runtime_dir and /Users/lgarron/Library/Caches in my case.)

Then listing sockets shows they are using different directories:

╭─── /Users/lgarron ─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
├─ lgarron@Pythagoras
│ lsof -U | grep foo1337
┴
zellij    17705 lgarron    5u  unix 0x7fb3184abea25da7      0t0      /tmp/zellij-501/0.41.1/foo1337
zellij    17705 lgarron    6u  unix 0x10dce4bdb80ef2de      0t0      /tmp/zellij-501/0.41.1/foo1337
zellij    17705 lgarron    7u  unix 0x10dce4bdb80ef2de      0t0      /tmp/zellij-501/0.41.1/foo1337
zellij    17790 lgarron    5u  unix  0x7c171ee524c6ea7      0t0      /var/folders/0j/2q1m_86950q5gjl4b1mt62f40000gn/T/zellij-501/0.41.1/foo1337
zellij    17790 lgarron    6u  unix 0xe637d6f2974046c2      0t0      /var/folders/0j/2q1m_86950q5gjl4b1mt62f40000gn/T/zellij-501/0.41.1/foo1337
zellij    17790 lgarron    7u  unix 0xe637d6f2974046c2      0t0      /var/folders/0j/2q1m_86950q5gjl4b1mt62f40000gn/T/zellij-501/0.41.1/foo1337
┬
╰─── ⏱️ 0.071s ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

This feels like a lot of experimentation and debugging to try to get the expected behaviour. I'd love to find a fix that can work for all macOS users, but I don't understand what zellij is doing.

[abitrolly]

If user is able to kill own zellij, it should be able to communicate with it running and ask it for socket to communicate. Am I right?

[lgarron]

This feels like a lot of experimentation and debugging to try to get the expected behaviour. I'd love to find a fix that can work for all macOS users, but I don't understand what zellij is doing.

I've tried to to keep $XDG_RUNTIME_DIR set and avoid doing anything fancy, but I'm still running into this all the time.

@tgulacsi, any chance you have any more debugging suggestions?

[lgarron]

I'm still questioning whether $XDG_RUNTIME_DIR is used at all. This code doesn't seem to use it:

zellij/zellij-utils/src/consts.rs

Line 161 in 2bd0f2a

.map_or_else(|| ZELLIJ_TMP_DIR.clone(), |p| p.to_owned())

Searching the codebase for "xdg" reveals this line:

zellij/zellij-server/src/lib.rs

Line 564 in 72f6b50

// https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html states that for XDG_RUNTIME_DIR:

… but doesn't show anything that seems to read the env var.

[lgarron]

I'm still questioning whether $XDG_RUNTIME_DIR is used at all. This code doesn't seem to use it:

Yeah, I think this is it.

If we let ⭐️ mean /var/folders/0j/2q1m_86950q5gjl4b1mt62f40000gn/T in my case, then:

How	mktemp on commandline	$TMPDIR on commandline	Path used by zellij
macOS in Terminal.app	⭐️	⭐️	⭐️
macOS over SSH	⭐️	⭐️	⭐️
macOS in iTerm.app	⭐️	(empty)	/tmp/

I can confirm that a connection over SSH has no issue connecting to the same sessions as a shell in Terminal.app. So the issues appear to be:

• zellij is not actually using $XDG_RUNTIME_DIR at all.
• The computed temporary dir is different in iTerm.app, presumably because $TMPDIR is not set.

Unfortunately:

• Despite what the Rust docs suggest, I'm finding that setting set -x TMPDIR (dirname (dirname (mktemp))) does not fix the issue in iTerm¹, even if I killall zellij to reset memory state.
• If I send a PR for $XDG_RUNTIME_DIR that certainly doesn't solve the problem for other iTerm users.

The only solutions that would work out of the box are:

1. Hardcode /tmp/ as the temp dir root, at least on macOS. This is less safe.
2. Implement macOS-specific logic. Since the mktemp command gets the correct path even when $TMPDIR is not set, this implies the "correct" temp dir should be possible to access in a minimally hacky way.

I would appreciate input from the maintainers about how to handle this in a PR.

Footnotes

1. EDIT: Turns out set -x TMPDIR (dirname (mktemp)) does work. ↩