Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wezterm Multiplexing connect server error. #5200

Open
qinyuntan opened this issue Mar 21, 2024 · 3 comments
Open

wezterm Multiplexing connect server error. #5200

qinyuntan opened this issue Mar 21, 2024 · 3 comments
Labels
bug Something isn't working

Comments

@qinyuntan
Copy link

What Operating System(s) are you seeing this problem on?

Linux X11, macOS

Which Wayland compositor or X11 Window manager(s) are you using?

No response

WezTerm version

20240203-110809-5046fc22

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

Yes, and I updated the version box above to show the version of the nightly that I tried

Describe the bug

Hi, when i use Multiplexing to connect my server linux. I got an error:
$: wezterm connect my
2024-03-21 13:56:22.777 wezterm-gui[10013:181624] WARNING: Secure coding is not enabled for restorable state! Enable secure coding by implementing NSApplicationDelegate.applicationSupportsSecureRestorableState: and returning YES.
13:56:23.348 ERROR wezterm_client::client > ssh stderr: zsh:1: command not found: wezterm

13:56:23.348 ERROR wezterm_client::client > wezterm cli --prefer-mux proxy: Exited with code 127
13:56:23.348 ERROR wezterm_client::client > Error while decoding response pdu: decoding a PDU: reading PDU length: EOF while reading leb128 encoded value
13:56:23.349 ERROR wezterm_gui > Please install the same version of wezterm on both the client and server! The server reported error 'Error while decoding response pdu: decoding a PDU: reading PDU length: EOF while reading leb128 encoded value' while being asked for its version. This likely means that the server is older than the client.
; terminating
13:56:23.349 ERROR mux::connui > while running ConnectionUI loop: recv_timeout: channel is empty and disconnected

And my client wezterm version is the same with server
20240203-110809-5046fc22

And in client macos, i add an export to my ~/.zshrc:
export PATH=$PATH:/Applications/WezTerm.app/Contents/MacOS

I have do the same config in my server:
export PATH=$PATH:/home/myworkspace/tools/wezterm/target/release

And either in client and server , i can use wezterm command indirect.

What can i do to solve this problem?

To Reproduce

No response

Configuration

no need

Expected Behavior

No response

Logs

No response

Anything else?

No response

@qinyuntan qinyuntan added the bug Something isn't working label Mar 21, 2024
@alvin883
Copy link

Hi I'm trying wezterm and I have the same issue, did you able to find solution / workaround?

in my case, I tried to connect to MacOs from Fedora (Wayland) and the same error appear although if I do it in reverse (connect to Fedora from MacOs) it works just fine

both machine are using the same version (20240203-110809-5046fc22)

here is the error:

14:46:17.469  ERROR  wezterm_client::client > ssh stderr: zsh:1: command not found: wezterm

14:46:17.570  ERROR  wezterm_client::client > wezterm cli --prefer-mux proxy: Exited with code 127
14:46:17.570  ERROR  wezterm_client::client > Error while decoding response pdu: decoding a PDU: reading PDU length: EOF while reading leb128 encoded value
14:46:17.570  ERROR  mux::connui            > while running ConnectionUI loop: recv_timeout: channel is empty and disconnected
14:46:17.571  ERROR  wezterm_gui            > Please install the same version of wezterm on both the client and server! The server reported error 'Error while decoding response pdu: decoding a PDU: reading PDU length: EOF while reading leb128 encoded value' while being asked for its version.  This likely means that the server is older than the client.
; terminating

Thanks!

@alvin883
Copy link

TL;DR

in my case, it turns out that the wezterm PATH on MacOS for non-interactive ssh is missing. It's in the first error line, the rest of error message is irrelevant

I think non-interactive ssh is the mode that wezterm connect use by default *CMIIW


Step by step guide:

how do you check the path to wezterm? you can run this on the host machine (MacOS in my case):

$ which wezterm
# in my case the output is: /opt/homebrew/bin

how do you check that path above is missing in ssh connection? you can run this on the guest machine (Fedora in my case):

$ ssh alvinnovian@mac env | grep PATH
# in my case the output is: PATH=/Users/alvinnovian/.cargo/bin:/usr/bin:/bin:/usr/sbin:/sbin

notice there's no /opt/homebrew/bin, so how do I add that? I follow this step (docker/cli#2115 (comment)) which was originally for docker, but the same step apply . step:

  1. edit /etc/ssh/sshd_config and set PermitUserEnvironment yes
  2. edit ~/.ssh/environment and add PATH=/usr/bin:/bin:/usr/sbin:/sbin:/opt/homebrew/bin
  3. restart sshd (on MacOS: go to System Settings > General > Sharing, toggle the "Remote Login" switch on and off)

and then confirm that wezterm path has been added from the guest machine

$ ssh alvinnovian@mac env | grep PATH
# output: PATH=/Users/alvinnovian/.cargo/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/homebrew/bin

if it's already exist, try to connect again:

$ wezterm connect mac

and it works 🎉


for reference, I use minimal config for wezterm's config.ssh_domains

config.ssh_domains = {
  {
    name = 'mac',
    remote_address = '<ip-address>',
    username = 'alvinnovian',
  }
}

@fhelmberger
Copy link

I ran into the same issue.

I was able get it to work by using the remote_wezterm_path option in the ssh_domains config:

config.ssh_domains = {
  {
    name = "srv",
    remote_address = "srv",
    username = "fhelmberger",
    remote_wezterm_path = "/home/linuxbrew/.linuxbrew/bin/wezterm",
  }
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants