Emacs Tramp is being blocked in creating sockets

[Troy]

If I understand what is happening here correctly, SUSE Leap has placed a 108 character limit on socket names. Emacs tramp is uniquifying socket names by adding an MD5sum to the name. Hence, when it goes to make a socket at any depth in the file tree, it exceeds 108 chars, and thus fails to be able to SSH out of the box.

Though, given all the AppArmor problems, perhaps Trramp fails due to that. But I have noticed, if I force the socket names to /tmp, so as to remove a few characters from the front, then it works.

So how is that limit changed?

[ikanotheokara]

This isn’t a restriction imposed by Leap, it’s a limitation present in all Linux systems. From the FAQ:

I get an error ‘unix_listener: path “/very/long/path/.cache/emacs/tramp.XXX” too long for Unix domain socket’ when connecting via ssh to a remote host.

By default, TRAMP uses the directory ~/.cache/emacs/ for creation of OpenSSH Unix domain sockets. On GNU/Linux, domain sockets have a much lower maximum path length (currently 107 characters) than normal files.

You can change this directory by setting the user option small-temporary-file-directory to another name, like

(unless small-temporary-file-directory
  (customize-set-variable
   'small-temporary-file-directory
  (format "/run/user/%d/emacs/" (user-uid)))
(make-directory small-temporary-file-directory t))

"/run/user/UID" is the value of the environment variable XDG_RUNTIME_DIR, which you can use instead via (getenv "XDG_RUNTIME_DIR").

Maybe somebody else knows a better workaround, but that’s what the manual says at least.

[Troy]

Still then, something difficult to explain. On the Debian system with the same user mounted, doing the same ssh using Tramp in emacs, it worked, and has worked for a long long time. Unmounted the home, updated to Suse, to to perform a the usual task of ssh’ing to another system to run updates, and it is broken.

So if it is a Linux thing in general, then it is a new Linux thing that has come up since about a month ago.

‘that is what the manual says’ ouch. Yes, I did do something similar to that, and put the sockets under /tmp, but that only saves a dozen characters or so. Probably enough, but not a very satisfying solution.

[ikanotheokara]

@Troy

On the Debian system with the same user mounted, doing the same ssh using Tramp in emacs, it worked, and has worked for a long long time.

Maybe the Debian system already has/had a workaround configured? Debian has the same socket path limitation of 107 characters.

@Troy

So if it is a Linux thing in general, then it is a new Linux thing that has come up since about a month ago.

It’s not a new limitation. I’m not sure what workaround was being used on the Debian system, but AFAIK this is a universal limitation in GNU/Linux and UNIX systems.

@Troy

‘that is what the manual says’ ouch. Yes, I did do something similar to that, and put the sockets under /tmp, but that only saves a dozen characters or so. Probably enough, but not a very satisfying solution.

Sorry, I didn’t mean that as some kind of “RTFM” dig at your expense. I just meant that I don’t really know any more about it than what the manual says. Maybe there is a fancier solution somewhere, but I can’t find one.

[knurpht]

What you can do, is using symlinks. Let’s say you have a path < /90/chars/here/>, then you could create a 90char symlink to that folder in /tmp/, and refer to /tmp/90char as the socket path.
Mind, I’ve been reading bits and pieces everywhere, the above is my wording of what I found going through the results that Perplexity came up with, where I selected most results pointing to kernel.org