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

Unable to mux into WSL from windows, wezterm-mux-server seems to ignore all config options #604

Closed
gnur opened this issue Apr 1, 2021 · 8 comments
Labels
bug Something isn't working waiting-on-op Waiting for more information from the original poster Windows Issue applies to Microsoft Windows

Comments

@gnur
Copy link

gnur commented Apr 1, 2021

Describe the bug

No matter the combination of commandline flags and config files, the wezterm-mux-server always starts its socket at ~/.local/share/wezterm/sock.

Environment (please complete the following information):

  • OS: windows 10 with wsl debian
  • Version: wezterm 20210314-114017-04b7cedd-120-g217dbfb9

To Reproduce

Steps to reproduce the behavior.

Follow the docs on https://wezfurlong.org/wezterm/multiplexing.html#connecting-into-windows-subsystem-for-linux

Configuration

wsl config

erwin@ARGUO:~$ cat .config/wezterm/wezterm.lua
return {
  unix_domains = {
    {
      name = "wsl"
      -- Override the default path to match the default on the host win32
      -- filesystem.  This will allow the host to connect into the WSL
      -- container.
      socket_path = "/mnt/c/Users/Erwin/.local/share/wezterm/sock",
      -- NTFS permissions will always be "wrong", so skip that check
      skip_permissions_check = true,
    }
  }
}

windows side config:

local wezterm = require 'wezterm';
return {
  font = wezterm.font("Cascadia Code PL"),
  color_scheme = "N0tch2k",
  unix_domains = {
    {
      name = "wsl",
      connect_automatically = true,
      serve_command = {"wsl", "wezterm-mux-server", "--daemonize"},
    }
  }
}

Expected behavior

Expect to get a wezterm window with a shell of my wsl debian install.

Screenshots

erwin@ARGUO:~$ wezterm-mux-server --config-file .config/wezterm/wezterm.lua
 2021-04-01T08:34:35.331Z INFO  wezterm_mux_server_impl::local > setting up /home/erwin/.local/share/wezterm/soc

2021-04-01 (2)

@gnur gnur added the bug Something isn't working label Apr 1, 2021
@wez wez added the Windows Issue applies to Microsoft Windows label Apr 3, 2021
@wez
Copy link
Member

wez commented Apr 3, 2021

inside wsl, please run:

WEZTERM_LOG=trace wezterm-mux-server 2> /tmp/server.txt

and attach /tmp/server.txt to this issue; that should show some diagnostics and help to understand what the server is up to.

@wez wez assigned gnur Apr 4, 2021
@gnur
Copy link
Author

gnur commented Apr 6, 2021

server.txt

I've added the server.txt file.

@wez wez unassigned gnur Apr 16, 2021
@markhagemann
Copy link

markhagemann commented May 17, 2021

Your wsl config is missing a , after name = "wsl"

@markhagemann
Copy link

markhagemann commented May 18, 2021

socket path

Using the socket path provided in the wiki:

      socket_path = "/mnt/c/Users/mhagemann/.local/share/wezterm/sock",

The path is correct but the way it is forming it seems to be wrong with the alternating forward and back slashes?

Might be a firewall issue - will check

@wez
Copy link
Member

wez commented May 24, 2021

If you're using wsl2, then I don't think this will work using unix domain sockets: microsoft/WSL#5961

@wez
Copy link
Member

wez commented May 29, 2021

Please confirm whether you're running WSL 1 or WSL 2; WSL 2 doesn't currently support unix domain socket interop.

@wez wez added the waiting-on-op Waiting for more information from the original poster label May 29, 2021
@no-response
Copy link

no-response bot commented Jun 12, 2021

This issue has been automatically closed because there has been no response to the request for more information from the original author. With only the information that is currently in the issue, there isn't enough information to take further action. Please reach out if you have or find the answers we need so that we can investigate further.

@no-response no-response bot closed this as completed Jun 12, 2021
@github-actions
Copy link
Contributor

github-actions bot commented Feb 4, 2023

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 4, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working waiting-on-op Waiting for more information from the original poster Windows Issue applies to Microsoft Windows
Projects
None yet
Development

No branches or pull requests

3 participants