DistantLaunch error "vim/_editor.lua:0: Vim:Failed to start manager"

[InsaneZulol]

Hi, I'm getting following error executing :DistantLaunch ssh://neeeeet.net distant.args="--log-level trace --log-file /tmp/dist_launch.log":

Error executing vim.schedule lua callback: Vim:Error executing vim.schedule lua callback: vim/_editor.lua:0: Vim:Failed to start manager
stack traceback:
        [C]: in function 'nvim_exec2'
        vim/_editor.lua: in function 'cmd'
        .../pack/packer/start/distant.nvim/lua/distant-core/log.lua:150: in function <.../pack/packer/start/distant.nvim/lua/distant-core/log.lua:146>
        [C]: in function 'wait'
        ...ack/packer/start/distant.nvim/lua/distant-core/utils.lua:384: in function <...ack/packer/start/distant.nvim/lua/distant-core/utils.lua:382>
        [C]: in function 'pcall'
        ...k/packer/start/distant.nvim/lua/distant-core/manager.lua:381: in function <...k/packer/start/distant.nvim/lua/distant-core/manager.lua:354>
        [C]: in function 'wait'
        ...k/packer/start/distant.nvim/lua/distant-core/manager.lua:396: in function 'wait_for_listening'
        ...site/pack/packer/start/distant.nvim/lua/distant/init.lua:217: in function 'cb'
        .../pack/packer/start/distant.nvim/lua/distant-core/cli.lua:93: in function <.../pack/packer/start/distant.nvim/lua/distant-core/cli.lua:93>
stack traceback:
        [C]: in function 'wait'
        ...k/packer/start/distant.nvim/lua/distant-core/manager.lua:396: in function 'wait_for_listening'
        ...site/pack/packer/start/distant.nvim/lua/distant/init.lua:217: in function 'cb'
        .../pack/packer/start/distant.nvim/lua/distant-core/cli.lua:93: in function <.../pack/packer/start/distant.nvim/lua/distant-core/cli.lua:93>

My mess of packer config at the moment

Distant.nvim: 0.3 Distant version: 0.20. Tried with both gnu and musl. I've tried 0.20 alpha 13, but this resulted in compatibility check error. checkhealth distant:

My mess of packer config at the moment

➜  cat ~/.cache/nvim/distant.log
[ERROR Thu 20 Jul 2023 11:11:55 AM CEST] ...site/pack/packer/start/distant.nvim/lua/distant/init.lua:210: Manager failed: "Exited unexpectedly: exit code 1"
[WARN  Thu 20 Jul 2023 11:26:08 AM CEST] ...site/pack/packer/start/distant.nvim/lua/distant/init.lua:544: distant:setup() called more than once! Ignoring new call to setup.
[WARN  Thu 20 Jul 2023 11:44:08 AM CEST] ...site/pack/packer/start/distant.nvim/lua/distant/init.lua:544: distant:setup() called more than once! Ignoring new call to setup.
[WARN  Thu 20 Jul 2023 11:44:15 AM CEST] ...site/pack/packer/start/distant.nvim/lua/distant/init.lua:544: distant:setup() called more than once! Ignoring new call to setup.
[ERROR Thu 20 Jul 2023 11:46:19 AM CEST] ...site/pack/packer/start/distant.nvim/lua/distant/init.lua:210: Manager failed: "Exited unexpectedly: exit code 1"                                                  

[chipsenkbeil]

It looks like the manager is failing to start. There's a couple of things we can do to diagnose:

1. What happens if you try running distant manager listen from the terminal? Does it run correctly? Or fail with an error?
2. Add to your setup a log file for the manager. From there, we can see if the manager gets to log anything before it fails that explains what is going on.

[InsaneZulol]

1. Damn it, I borked distant:

  4 [2023-07-21 10:16:06.397692 +02:00] INFO [src/cli/commands/manager.rs:176] Starting manager (network = global)
  3 [2023-07-21 10:16:06.398541 +02:00] ERROR [src/lib.rs:143] Failed to start manager
  2
  1 Caused by:
  5       No such file or directory (os error 2)                                                                                                      

2. Manager didn't even get to log to that new file, only updated ~/.cache/distant/manager.log

I reinstalled from the script curl -L https://sh.distant.dev | sh, so I'm not sure what I'm missing.

[chipsenkbeil]

What operating system are you using? On Unix-like systems (Linux, MacOS, FreeBSD) a socket file is created, but the error message isn't really giving us details, which is surprising.

Try a different Unix domain socket path

You can try something like distant manager listen --user or distant manager listen --unix-socket /tmp/distant.sock to see if the manager will run.

When it says network = global, the socket file is going to be created in one of these paths:

• /run/distant.sock on Linux
• /var/run/distant.sock on BSD
• /tmp/distant.dock on MacOS

If you supply --user, it will instead create a socket in one of these paths:

• /run/user/{user_id}/distant/{user}.distant.sock on Linux
• /var/run/{user}.distant.sock on BSD
• /tmp/{user}.distant.dock on MacOS

The full path should be created automatically for you. Not sure why it's giving an error instead.

Unix domain socket paths

If changing the socket path works, you can specify it as part of your setup process:

require('distant'):setup({
    ['network.unix_socket'] = '/tmp/distant.sock',
})

Use a private network

You can also use a private network, which will create the Unix domain socket in a local path tied to neovim itself:

require('distant'):setup({
    ['network.private'] = true,
})

[anchorite]

Hello,

I had a similar issue and using strace and execsnoop(from bcc) I noticed that:

1. I didn't have a config file in ~/.config/distant/config.toml and according to documentation I generated a default one using distant generate config --output $HOME/.config/distant/config.toml.
2. Needed to provide the user = true configuration option for manager as it was trying to create a system-wide socket in a path to which it didn't have access to.

Note also that distant is not in my $PATH so I also needed to modify the config file and pass the full path to the executable.

After the above it was able to connect to a remote server and open files, etc.

Hope this helps in your case. Cheers.

[InsaneZulol]

What operating system are you using?

It's Ubuntu 22.04.1 LTS. WSL unfortunately - corporate laptop.
For some reason I'm not having any sockets created and 'hanging' in /run/. Maybe it doesn't have access to the that dir.

You can also use a private network, which will create the Unix domain socket in a local path tied to neovim itself:

require('distant'):setup({ ['network.private'] = true, })

Thanks, that worked. I've checked session info and apparently I'm using a windows pipe through WSL. Isn't this maybe odd?

@anchorite Yeah I didn't have a config.toml either. I've foregone generating it tho.

[chipsenkbeil]

Windows pipe on WSL

I haven't checked WSL, but neovim will supply distant with both a windows pipe and unix domain socket as options. Distant itself "should" detect which one to use for you. Do you see a socket file created? If so, then it's using the socket file. This is baked into which version of distant you're using, the one compiled for Windows or the one compiled for Linux (if you're using WSL). The one compiled for Linux will always using a domain socket while the one compiled for Windows will always use a Windows pipe.

The UI is just showing you both. If you find this confusing, we could add a check in neovim to see if you're in Linux to show the socket or Windows to show the pipe in the UI, hiding the other one.

Color Scheme

@InsaneZulol hm, that color scheme doesn't look right. It should ideally be something like below. I haven't actually checked the colorscheme on default neovim as I'd used the same scheme as mason.nvim, which I assumed worked. Seems like I may need to both tweak the default colors and make it so it's easier to customize the colors yourself.

Networking

I may switch v0.3 to use a private network by default since it seems like there's a lot of issues getting started otherwise. This is good user feedback 😄

You can start a manager outside of neovim and - when not using private - neovim should connect to it. This goes for the global socket or the user-local socket. If you use a custom socket path, it won't know where to find it unless you also provide that in the configuration.

Config file

You shouldn't need to create the configuration file, but it won't hurt to do so. I would expect to see an access attempt from strace that @anchorite saw, but when it fails to load, the default configuration is used instead. This is the same configuration you get from generating it! :)

[timnolte]

I tried all of these tips, I'm in a Linux virtual environment on a Chromebook. I'm trying to use this along with the DevPod CLI which starts up a Devcontainer that I can SSH into. When I attempt to connect I first get a prompt/notice that the host is not yet trusted. When I answer with a y it ends up just returning a Exited unexpectedly: exit code 1. If I check the logs all I get is:

[2023-10-23 23:59:54.277313 -04:00] INFO [src/cli/commands/manager.rs:176] Starting manager (network = custom:unix:"/home/tim/.cache/nvim/distant.nvim/nvim-2853.sock")
[2023-10-23 23:59:54.278346 -04:00] INFO [src/cli/common/manager.rs:51] Manager listening using unix socket @ "/home/tim/.cache/nvim/distant.nvim/nvim-2853.sock"
[2023-10-23 23:59:54.278406 -04:00] INFO [distant-net/src/server/shutdown_timer.rs:58] Server shutdown timer configured: never terminate
[2023-10-23 23:59:54.290398 -04:00] INFO [distant-net/src/common/connection.rs:344] [Conn 729087134] Connect completed successfully!
[2023-10-23 23:59:54.290488 -04:00] INFO [distant-net/src/server/connection.rs:456] [Conn 729087134] Connection established
[2023-10-23 23:59:54.290532 -04:00] INFO [distant-net/src/manager/server.rs:358] Retrieved list of connections
[2023-10-23 23:59:54.309181 -04:00] INFO [distant-net/src/common/connection.rs:344] [Conn 3181779806] Connect completed successfully!
[2023-10-23 23:59:54.309214 -04:00] INFO [distant-net/src/server/connection.rs:456] [Conn 3181779806] Connection established
[2023-10-23 23:59:54.311429 -04:00] INFO [distant-net/src/manager/server.rs:230] Launching ssh://openid-connect-generic.devpod with distant.bind_server="ssh",distant.bin="distant",distant.args=""

If I attempt to use the distant CLI command in my terminal after manually starting up the listener I get an error that it can't establish a tunnel.

[chipsenkbeil]

I tried all of these tips, I'm in a Linux virtual environment on a Chromebook. I'm trying to use this along with the DevPod CLI which starts up a Devcontainer that I can SSH into. When I attempt to connect I first get a prompt/notice that the host is not yet trusted. When I answer with a y it ends up just returning a Exited unexpectedly: exit code 1. If I check the logs all I get is:

[2023-10-23 23:59:54.277313 -04:00] INFO [src/cli/commands/manager.rs:176] Starting manager (network = custom:unix:"/home/tim/.cache/nvim/distant.nvim/nvim-2853.sock")
[2023-10-23 23:59:54.278346 -04:00] INFO [src/cli/common/manager.rs:51] Manager listening using unix socket @ "/home/tim/.cache/nvim/distant.nvim/nvim-2853.sock"
[2023-10-23 23:59:54.278406 -04:00] INFO [distant-net/src/server/shutdown_timer.rs:58] Server shutdown timer configured: never terminate
[2023-10-23 23:59:54.290398 -04:00] INFO [distant-net/src/common/connection.rs:344] [Conn 729087134] Connect completed successfully!
[2023-10-23 23:59:54.290488 -04:00] INFO [distant-net/src/server/connection.rs:456] [Conn 729087134] Connection established
[2023-10-23 23:59:54.290532 -04:00] INFO [distant-net/src/manager/server.rs:358] Retrieved list of connections
[2023-10-23 23:59:54.309181 -04:00] INFO [distant-net/src/common/connection.rs:344] [Conn 3181779806] Connect completed successfully!
[2023-10-23 23:59:54.309214 -04:00] INFO [distant-net/src/server/connection.rs:456] [Conn 3181779806] Connection established
[2023-10-23 23:59:54.311429 -04:00] INFO [distant-net/src/manager/server.rs:230] Launching ssh://openid-connect-generic.devpod with distant.bind_server="ssh",distant.bin="distant",distant.args=""

If I attempt to use the distant CLI command in my terminal after manually starting up the listener I get an error that it can't establish a tunnel.

Does the devcontainer have the distant CLI inside it? Or are you trying to use pure ssh? If pure ssh, use connect instead of launch. If you're using the distant inside the container, can you use the --distant cli option during launch to specify the full path to the binary?

Lastly, if you're using distant inside the container, can you try starting distant from inside and then connecting to it versus launching to it? You'll need to get the key printed when manually starting the distant server to provide when connecting to it, though.