This improves the heartbeat detection logic. We now treat any other
incoming message from the ssh remote server
as a heartbeat message, meaning that we can detect re-connects earlier.
It also changes the connection handling to await futures detached.
Co-Authored-by: Thorsten <thorsten@zed.dev>
Release Notes:
- N/A
---------
Co-authored-by: Thorsten <thorsten@zed.dev>
Co-authored-by: Antonio <antonio@zed.dev>
remote: Disable ControlPersist for master ssh connection
`ControlPersist=yes` combined with `ControlMaster=yes` silently forces
`ForkAfterAuthentication=yes` (even when the user has explicitly set it
to `no` - reported upstream in [0]) - and the latter makes the ssh
subprocess disappear, which makes us think that the connection died
(This is only an issue for people who have `ControlPersist=yes` in their
`ssh_config`, and perhaps the answer is "if that option breaks things,
don't use that option?" - but it's an option that makes sense _most_ of
the time, it's just in this edge-case of "creating an ssh connection
with -N and expecting the process to stay in the foreground" where it
_must_ be set to no)
I think the alternative approach is to tell people "if you want to use
persistent connections, have a separate ~/.ssh/config entry for
servername (to ssh into) and servername-no-persist (to zed into)", which
is possible, but ugh. Kind of a messy situation >.<
Tests:
- Before: Connections to my server result in "Failed to connect: ." (The
error message is attempting to show stderr, but stderr is empty)
- After: Connections to my server work reliably
[0] https://bugzilla.mindrot.org/show_bug.cgi?id=3743
Release Notes:
- N/A
This will allow us to compile debug builds of the remote-server for a
different architecture than the one we are developing on.
This also adds a CI step for building our remote server with minimal
dependencies.
Release Notes:
- N/A
This ensures that we only ever reconnect to a running server and not
spawn a new server with no state.
This avoids the problem of the server process crashing, `proxy`
reconnecting, starting a new server, and the user getting errors like
"unknown buffer id: ...".
Release Notes:
- N/A
---------
Co-authored-by: Bennet Bo Fenner <bennet@zed.dev>
Previously, the connection process would be cancelled after 10 seconds,
even if the connection was established successfully but the user was
still typing in a password.
We know recognize when the user is prompted for a password, and cancel
the timeout task.
Co-Authored-by: Thorsten <thorsten@zed.dev>
Release Notes:
- N/A
---------
Co-authored-by: Thorsten <thorsten@zed.dev>
To detect connection timeouts we ping the remote server every X seconds
and attempt to reconnect if the server failed to respond.
Next up is showing some feedback in the UI to make this visible to the
user, and stop reconnecting after X amount of retries.
Release Notes:
- N/A
---------
Co-authored-by: Thorsten <thorsten@zed.dev>
The indicator turns yellow when ssh client is trying to reconnect. Note
that the state tracking is probably not ideal (we'll see how it pans out
once we start dog-fooding), but at the very least "green=good" should be
a decent mental model for now.
Release Notes:
- N/A
We introduced a memory leak in #18572, which meant that `Drop` was never
called on `SshRemoteConnection`, meaning that the ssh process kept
running
Co-Authored-by: Thorsten <thorsten@zed.dev>
Release Notes:
- N/A
---------
Co-authored-by: Thorsten <thorsten@zed.dev>
This restructures the code in `remote` so that it's easier to replace
the current SSH connection with a new one in case of
disconnects/reconnects.
Right now, it successfully reconnects, BUT we're still missing the big
piece on the server-side: keeping the server process alive and
reconnecting to the same process that keeps the project-state.
Release Notes:
- N/A
---------
Co-authored-by: Bennet <bennet@zed.dev>
This shows an error if opening a connection to a remote host didn't work
in the timeout of 10s (maybe we'll need to make that configurable in the
future? for now it seems fine.)
Release Notes:
- N/A
---------
Co-authored-by: Bennet <bennet@zed.dev>
Co-authored-by: Conrad <conrad@zed.dev>
This was a process leak. Since we use `.spawn()`, the process continued
to run in the background, even if our `SshClientState` was dropped.
Means we need to manually clean it up.
Release Notes:
- N/A
Co-authored-by: Bennet <bennet@zed.dev>
This fixes the `SshSession` being leaked.
There were two leaks:
1. `Arc<SshSession>` itself got leaked into the `SettingsObserver` that
lives as long as the application. Fixed with a weak reference.
2. The two tasks spawned by an `SshSession` had a circular dependency
and didn't exit while the other one was running. Fixed by fixing (1)
and then attaching one of the tasks to the `SshSession`, which means
it gets dropped with the session itself, which leads the other task
to error and exit.
Co-authored-by: Bennet <bennet@zed.dev>
Release Notes:
- N/A
---------
Co-authored-by: Bennet <bennet@zed.dev>
TODOs:
- [x] Add tests to `workspace/src/persistence.rs`
- [x] Add a icon for ssh projects
- [x] Fix all `TODO` comments
- [x] Use `port` if it's passed in the ssh connection options
In next PRs:
- Make sure unsaved buffers are persisted/restored, along with other
items/layout
- Handle multiple paths/worktrees correctly
Release Notes:
- N/A
---------
Co-authored-by: Bennet Bo Fenner <bennet@zed.dev>
This is a refactor to prepare for adding LSP support in SSH remote
projects.
Release Notes:
- N/A
---------
Co-authored-by: Mikayla <mikayla@zed.dev>
Co-authored-by: Conrad <conrad@zed.dev>
For ssh remoting lsps we'll need to have language server support
factored out of project.
Thus that begins
Release Notes:
- N/A
---------
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
Co-authored-by: Mikayla <mikayla@zed.dev>
This also rolls back the `TerminalWorkDir` abstraction I added for the
original remoting, and tidies up the terminal creation code to be clear
about whether we're creating a task *or* a terminal. The previous logic
was a little muddy because it assumed we could be doing both at the same
time (which was not true).
Release Notes:
- remoting alpha: Removed the ability to specify `gh cs ssh` or `gcloud
compute ssh` etc. See https://zed.dev/docs/remote-development for
alternatives.
- remoting alpha: Added support for terminal and tasks to new
experimental ssh remoting
Still TODO:
* [x] hide this UI unless you have some ssh projects in settings
* [x] add the "open folder" flow with the new open picker
* [ ] integrate with recent projects / workspace restoration
Release Notes:
- N/A
* Fixed mis-named macOS remote server archives in actions and packaging
scripts
* Fixed an issue with the ask pass script on linux
* Download nightly versions of remote servers in dev mode (not stable)
Release Notes:
- N/A
This is a first step towards allowing you to edit remote projects
directly over SSH. We'll start with a pretty bare-bones feature set, and
incrementally add further features.
### Todo
Distribution
* [x] Build nightly releases of `zed-remote-server` binaries
* [x] linux (arm + x86)
* [x] mac (arm + x86)
* [x] Build stable + preview releases of `zed-remote-server`
* [x] download and cache remote server binaries as needed when opening
ssh project
* [x] ensure server has the latest version of the binary
Auth
* [x] allow specifying password at the command line
* [x] auth via ssh keys
* [x] UI password prompt
Features
* [x] upload remote server binary to server automatically
* [x] opening directories
* [x] tracking file system updates
* [x] opening, editing, saving buffers
* [ ] file operations (rename, delete, create)
* [ ] git diffs
* [ ] project search
Release Notes:
- N/A
---------
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
