remote-ssh session with disconnects

[r2evans]

When working over a network connection that glitches, the entire R process dies, that can be catastrophic for in-work processes. What best-practices are available to mitigate this?

Perhaps an option is to allow the user to customize the command line when calling an interpreter?

As an example, I use dtach (emulates the "detach" functionality of screen) with R so that one can reconnect to a disconnected R process. I do this regularly for several reasons, supporting long-running R processes that can be headless or (re)connected without interruption. This is distinct from the use of tmux, screen, byobu, and other similar utilities that are much more geared towards being a full multiplexer than "just" supporting a simple/single connection.

(Background: I'm an emacs/ess user and regularly have 3+ R sessions running in my emacs sessions. Occasionally I like to disconnect an R session and get back to it later or from elsewhere.)

[jmcphers]

You can configure Positron to leave R running for a set time period after Positron itself is closed. If you re-open Positron (in the same workspace, on the same machine) and the R session is still running, Positron will re-attach to it instead of creating a new session. You can find that setting here:

No tools yet to manage these sessions (they are implicitly bound to a workspace); work on that is outlined here: #5982

[r2evans]

Thank you! I didn't know about that setting. I had been looking for "disconnect", now I found https://positron.posit.co/remote-ssh.html#shutdown-timeout-details.

I think I found a bug in that it inconsistently discovers sessions to resume. For instance, with Positron running on my local macos, same user, connecting to the same ssh remote. I set the shutdown timeout to 4h for this test.

1. Start positron, connect to the ssh remote, Sys.getpid() is 1879887. Quit Positron.
2. Confirm the remote PID 1879887 is still running.
3. Start positron, connect to the ssh remote, PID is 1880643. Quit.
4. Confirm the remote PIDs 1879887 and 1880643 are still running.
5. Start positron, connect to the ssh remote, PID is again 1880643, same session. Success! Quit.
6. Confirm the remote PIDs are still running.
7. Start, connect, PID is 1884045. Quit.
8. Remote PIDs 1879887, 1880643, and 1884045 are all still running.

(you get the idea)

I understand there are no tools yet for managing these sessions. I found that I could easily find sessions with ps fax | grep [a]rk/ark, though since I could not reconnect via Positron, my only recourse to stop them was with kill using one of USR1, USR2, or KILL, none of INT, HUP, nor TERM appeared to do anything. I'm comfortable looking for and managing these, but the fact that I don't know how to be able to reconnect to individual sessions is problematic.

I think that sessions are intended to be held unique by the remote directory (a "project" in a sense), is that right? Is the recommended way to run multiple remote long-running sessions to start them in unique directories?

[r2evans]

I'm now seeing #6692, likely the same thing.

[jmcphers]

I think that sessions are intended to be held unique by the remote directory (a "project" in a sense), is that right?

Yes, your R or Python sessions are considered to be project scoped -- so you need to open the same project.

I agree that you're seeing #6692 which I haven't been able to reproduce yet (but it's good to have another report!). In your example above, were you inside a project/directory? Or do you have no project open, like this?

[r2evans]

I was not in a directory, not a project, and I had no interpreters running. That suggests the notion of "project" (for consistency) is undefined in that scenario.

Btw, is there a way to use it without this notion of a "project"? I get why that works for so many, but it doesn't match 90% of my workflow.

I'll try to rerun the conditions tomorrow while I'm a "project" (but I really want to find a safe way to not be constrained by projects :-).

[r2evans]

Confirmed: starting with Positron in a directory (that happens to be an R package as a git repo) with an R interpreter running: "Remote Host", start remote interpreter, PID 1935122; quit the remote-session positron window; reconnect, start remote interpreter, new PID, both exist on the server.

Looking at the remote process fix ps 1935122, the command line has a hashed path under ~/.positron-server/.... Is there a clear mapping somewhere that will translate the random /tmp/kernel-*/ directories to the originating-host project dir?

I'm happy to work with you to refine this scenario, either here or in #6692 if you'd prefer.