Open j-xella opened 1 year ago
is it a wezterm ssh
instance that goes away?
Most likely cause is that the ssh connection times out and gets shut down.
Try setting exit_behavior = "Hold"
to see if that helps to explain what happened
Yes, I have a host configured in %USERPROFILE%/.ssh/config
, and then invoke wezterm-gui ssh myhost
. Using your suggestion, I got the following error:
⚠️ Process RemoteSshDomain didn't exit cleanly
Exited with code 1.
This message is shown because exit_behavior="Hold"
The error appeared in the middle of the screen, but I guess this is because I had a neovim session open, and that is where the cursor was at the moment.
I left the session running overnight, so can't say exactly how long it took to fail. There is nothing in the logs about the failure, unless you run with DEBUG mode. In DEBUG mode, the logs can become huge, so I don't run in DEBUG mode every time. I think it would help if this error message on screen also contained timestamp, so that it would be possible to determine when wezterm closed. And if something would be written to the logs on such occasion even if running without WEZTERM_LOG=debug
.
This problem never happened when I was using Putty, but I always have keepalive enabled. I have looked around and for OpenSSH this would enable automatic keep-alive pinging:
Host *
ServerAliveInterval 300
ServerAliveCountMax 2
Does libssh support these options, and if not, what is the alternative?
OK, the ServerAlive*
options in SSH config file did not make any difference.
I have now opened a new workspace for the same ssh connection, and started a command in it that would constantly generate some output. Something like watch -n 5 date
. Let's see if this will prevent wezterm from closing.
SSH connection seems to get interrupted even when I am working - so this is unlikely to be a timeout issue due to inactivity.
Out of desperation, I have tried restarting my PC. This also does not seem to prevent the problem from reappearing.
I have also tried to start a putty connection to the same user@host, and leave it in the background. It does not fail when wezterm connection fails. Just in case this is some sort of my local network issue....
Then I started wezterm ssh -v myhost
. This enabled the whole new set of debug messages, with socket exception:
17:18:36.301 INFO libssh::ssh_packet_newkeys > Received SSH_MSG_NEWKEYS
17:18:36.303 INFO libssh::ssh_packet_newkeys > Signature verified and valid
17:18:36.305 INFO libssh::ssh_packet_set_newkeys > This direction isn't used anymore.
17:18:36.308 INFO libssh::ssh_channel_read_timeout > Read (8192) buffered : 0 bytes. Window: 793360
17:18:36.417 INFO libssh::ssh_channel_read_timeout > Read (8192) buffered : 0 bytes. Window: 793360
17:18:36.420 INFO libssh::ssh_channel_read_timeout > Read (8192) buffered : 0 bytes. Window: 793360
17:18:36.620 INFO libssh::ssh_channel_read_timeout > Read (8192) buffered : 0 bytes. Window: 793360
17:18:36.622 INFO libssh::ssh_channel_read_timeout > Read (8192) buffered : 0 bytes. Window: 793360
17:18:37.026 INFO libssh::ssh_channel_read_timeout > Read (8192) buffered : 0 bytes. Window: 793360
17:18:37.028 INFO libssh::ssh_channel_read_timeout > Read (8192) buffered : 0 bytes. Window: 793360
17:18:37.839 INFO libssh::ssh_channel_read_timeout > Read (8192) buffered : 0 bytes. Window: 793360
17:18:37.843 INFO libssh::ssh_channel_read_timeout > Read (8192) buffered : 0 bytes. Window: 793360
17:18:39.448 INFO libssh::ssh_channel_read_timeout > Read (8192) buffered : 0 bytes. Window: 793360
17:18:39.450 INFO libssh::ssh_channel_read_timeout > Read (8192) buffered : 0 bytes. Window: 793360
17:18:42.651 INFO libssh::ssh_channel_read_timeout > Read (8192) buffered : 0 bytes. Window: 793360
17:18:42.653 INFO libssh::ssh_channel_read_timeout > Read (8192) buffered : 0 bytes. Window: 793360
17:18:49.058 INFO libssh::ssh_channel_read_timeout > Read (8192) buffered : 0 bytes. Window: 793360
17:18:49.062 INFO libssh::ssh_channel_read_timeout > Read (8192) buffered : 0 bytes. Window: 793360
17:18:54.142 INFO libssh::ssh_socket_unbuffered_write > Enabling POLLOUT for socket
17:18:54.144 INFO libssh::packet_send2 > packet: wrote [type=94, len=28, padding_size=15, comp=12, payload=12]
17:18:54.148 INFO libssh::channel_write_common > channel_write wrote 3 bytes
17:18:54.152 INFO libssh::ssh_channel_read_timeout > Read (8192) buffered : 0 bytes. Window: 793360
17:18:54.153 INFO libssh::ssh_channel_read_timeout > Read (8192) buffered : 0 bytes. Window: 793360
17:18:54.154 INFO libssh::ssh_packet_need_rekey > rekey: [data_rekey_needed=0, out_blocks=1, in_blocks=1]
17:18:54.155 INFO libssh::ssh_socket_unbuffered_write > Enabling POLLOUT for socket
17:18:54.156 INFO libssh::packet_send2 > packet: wrote [type=94, len=28, padding_size=6, comp=21, payload=21]
17:18:54.158 INFO libssh::channel_write_common > channel_write wrote 12 bytes
17:18:54.159 INFO libssh::ssh_channel_read_timeout > Read (8192) buffered : 0 bytes. Window: 793360
17:18:54.160 INFO libssh::ssh_channel_read_timeout > Read (8192) buffered : 0 bytes. Window: 793360
17:18:54.179 INFO libssh::ssh_channel_read_timeout > Read (8192) buffered : 0 bytes. Window: 793360
17:18:54.181 INFO libssh::ssh_socket_exception_callback > Socket exception callback: 2 (10054)
17:18:54.181 INFO libssh::ssh_socket_exception_callback > Socket error: Unknown error
17:18:54.182 INFO libssh::ssh_channel_read_timeout > Read (8192) buffered : 0 bytes. Window: 793360
I am beginning to suspect that libssh shipped with wezterm does not work properly on Windows ....
the exception error code 10054 is WSAECONNRESET:
Connection reset by peer. An existing connection was forcibly closed by the remote host. This normally results if the peer application on the remote host is suddenly stopped, the host is rebooted, the host or remote network interface is disabled, or the remote host uses a hard close (see setsockopt for more information on the SO_LINGER option on the remote socket). This error may also result if a connection was broken due to keep-alive activity detecting a failure while one or more operations are in progress. Operations that were in progress fail with WSAENETRESET. Subsequent operations fail with WSAECONNRESET.
Following the idea that libssh is not behaving correctly, I restarted Wezterm with
config.ssh_backend = "Ssh2"
This seems to solve (or, rather, bypass) the issue for me - Wezterm is staying on for more than 24h so far.
To be fair, I have tried connecting to the same user@host from different Windows PC, and Wezterm works normally even with libssh backend. So there is something on this particular PC that makes libssh fail. And it is likely not easy to reproduce...
If there is any way to gather more insight into this issue, please let me know. Otherwise, I will maybe give libssh a go once wezterm is deployed with a newer version of it.
I have come across the same problem and the solution works for me. I have WezTerm installed in Windows and I have a .ssh/config
file with the relevant keepalive options, but they seem to be ignored by libssh. Switching to Ssh2 backend works, but degrades the experience as I need interactivity when keys become invalid.
What Operating System(s) are you seeing this problem on?
Windows
Which Wayland compositor or X11 Window manager(s) are you using?
No response
WezTerm version
20230408-112425-69ae8472 x86_64-pc-windows-msvc
Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?
No, and I'll explain why below
Describe the bug
I use Wezterm on Windows to connect to Linux via ssh. Wezterm runs for a while (an hour or 2), then closes spontaneously. Running with DEBUG enabled produces logs like this:
To Reproduce
Not sure how ... I just work, and after a while wezterm closes... Maybe logs can give a hint?
Wezterm is running on a PC that I RDP to. Several times I would lock the PC, and when I unlock it, wezterm is gone. Or, wezterm disappears when I switch focus back to it, often by clicking it with a mouse. But, obviously, it does not happen every time...
Configuration
Expected Behavior
Wezterm does not die.
Logs
Debug Overlay wezterm version: 20230408-112425-69ae8472 x86_64-pc-windows-msvc Window Environment: Windows OpenGL version: WebGPU: name=Quadro P400, device_type=DiscreteGpu, backend=Vulkan, driver=NVIDIA, driver_info=527.48, vendor=4318, device=7347 Enter lua statements or expressions and hit Enter.
Anything else?
No response