Skip to content

Inability to Attach active R terminal on Compute Nodes in HPC Environment #1541

Description

@XZhangGit

Describe the bug
When launching an active R terminal on a compute node within an HPC environment and attempting to attach it using .vsc.attach(), the terminal remains detached with the message "R: (not attached)" displayed. Clicking to attach does not initiate the attachment process. However, on the login node, the active R terminal automatically attaches as expected, likely due to the configuration in ~/.Rprofile. I found a similar issue reported by another user (https://stackoverflow.com/questions/73087813/how-do-i-make-sure-my-r-session-attached-is-using-the-compute-node-instead-of-th), where he mentioned "my data viewer wouldn't be attached and I couldn't view my data in the 'workspace'.", and there hasn't been a solution provided yet.

To Reproduce
Steps to reproduce the behavior:

  1. Launch an interactive R on the compute node on HPC.
  2. Run .vsc.attach() in R.
  3. Observe the terminal displaying "R: (not attached)" without successfully attaching.

**Can you fix this issue by yourself? **
No

Please attach setting.json

"r.alwaysUseActiveTerminal": true,
"r.bracketedPaste": true,
"r.sessionWatcher": true,
"r.rterm.option": [],
"r.rterm.linux": "/path/to/radian",

Expected behavior
The terminal should attach successfully to the interactive R session on the compute node when .vsc.attach() is called, similar to the behavior observed on the login node where it attaches automatically.

Screenshots
Terminal showing "R: (not attached)" when attempting to attach after running .vsc.attach():

Screenshot 2024-06-28 at 23 16 16

Screenshot 2024-06-28 at 23 20 33

Terminal automatically attached on the login node due to ~/.Rprofile configuration:

Screenshot 2024-06-28 at 23 24 46

Environment (please complete the following information):

  • OS: [Linux]
  • VSCode Version: [1.90.2]
  • R Version: [4.3.1]
  • REditorSupport version: [2.8.4]

Thank you!

Activity

  1. hariesramdhani commented on Jul 1, 2024

    @hariesramdhani

    Can also confirm that I encountered the same bug, thanks for raising the issue!

  2. krferrier commented on Aug 15, 2024

    @krferrier

    I am experiencing the same bug and would love a solution. I have no problem attaching an R-session from a login node, but can't attach an R session from an interactive compute node. The option to start an R Terminal works as well, but it uses a login node by default. I haven't been able to figure out why exactly the compute nodes are unable to see/use rlanguageserver options, nor how to modify the R Terminal to be initiated with a non-login node.

  3. Alkhawaja95 commented on Nov 28, 2024

    @Alkhawaja95

    I also report the same problem here. I would appreciate a guide or fix

  4. c-brendel commented on Feb 5, 2025

    @c-brendel

    I'm also running into the same problem!

    I think this is related to these isssues: #469, #552

    I guess the tmp folders are different on the login vs. compute nodes, and that's maybe part of the problem.

    I've tried to SSH directly into a compute node (and then maybe the paths would be set up correctly), but I haven't been able to get the SSH connection to work.

  5. hariesramdhani commented on Feb 5, 2025

    @hariesramdhani

    @c-brendel not directly related to the issue but my current getaway for running R interactively on the compute node is to use jupyter-server, more here https://www.morganlab.co.uk/wiki/working-with-hpc/running-a-jupyter-server

  6. benz0li commented on Feb 5, 2025

    @benz0li
    Contributor

    @c-brendel not directly related to the issue but my current getaway for running R interactively on the compute node is to use jupyter-server, more here https://www.morganlab.co.uk/wiki/working-with-hpc/running-a-jupyter-server

    Others seem to use Podman on HPC nodes to run images from the JupyterLab R docker stack1 in rootless mode.

    Cross reference:

    Footnotes

    1. These images includes code-server, aka Code - OSS. ↩

  7. c-brendel commented on Feb 5, 2025

    @c-brendel

    @c-brendel not directly related to the issue but my current getaway for running R interactively on the compute node is to use jupyter-server, more here https://www.morganlab.co.uk/wiki/working-with-hpc/running-a-jupyter-server

    I was able to follow these instructions to run R interactively on my compute node! Thanks!

  8. lgn-almeida commented on Jun 4, 2025

    @lgn-almeida

    I am also facing the same issue here. Using the login node, I created a conda env, installed r-base, and managed packages using renv (used install.packages("renv"), then all subsequent packages installed via renv::install(), including languageserver).
    I created a settings.json file with the following:

    {
        "r.rterm.linux": "/home/lgna/software/miniforge3/envs/scrna_jun2025/bin/R",
        "r.rpath.linux": "/home/lgna/software/miniforge3/envs/scrna_jun2025/bin/R",
        "r.rterm.option": [
            "--no-save",
            "--no-restore"
        ],
        "r.sessionWatcher": true,
        "r.alwaysUseActiveTerminal": true
    }
    

    When launching an interactive session via salloc, I must launch R in the active terminal to keep myself inside the job. This leads to R "not attached" and I've had no success attaching it. Interestingly, if I manually click to launch an "R Interactive" or press F1 followed by "R: Create R Terminal", then R successfully attaches, and everything works great BUT the terminal is launched at the login node, which I am not supposed to do.

    Lastly, I also tried the following in my .Rprofile:

    source(file.path(Sys.getenv(
       if (.Platform$OS.type == "windows") "USERPROFILE" else "HOME"
    ), ".vscode-R", "init.R"))
    

    When using this code on the profile, R does not attach. I click on the R: (not attached) it runs the .vsc.attach() but nothing happens.

    Not sure if this is related, but I get the same issue in my WSL/Ubuntu installation. There, all R packages are managed by my conda env. Things work beautifully if "r.alwaysUseActiveTerminal": false, but whenever I set "r.alwaysUseActiveTerminal": true, then R cannot be attached.

    Happy to provide more info as needed!

  9. lgn-almeida commented on Jun 6, 2025

    @lgn-almeida

    I wrote a script to force Reditorsupport to launch its interactive terminal in a new job session, with the goal of avoiding the login node. It didn't solve the issue. Not sure if I am missing something on my script, but this could be further evidence that .vsc.attach is having a hard time launching in interactive job sessions?

    Here is my code:

    #!/bin/bash
    
    # Adjust with your conda env name
    ENV_NAME=conda_R
    
    # Load modules or conda init if needed
    source ~/software/init-mamba  # or wherever your conda is
    
    # Activate environment
    mamba activate "$ENV_NAME"
    
    # Start SLURM interactive session and launch R
    srun --time=01:00:00 --mem=4G --ntasks=1 --pty R
    

    My settings.json:

    {
        "r.rterm.linux": "/home/lgna/projects/test_r/launch_r_vscode.sh",
        "r.rpath.linux": "/home/lgna/software/miniforge3/envs/conda_R/bin/R",
        "terminal.integrated.env.linux": {
            "R_HOME": "/home/lgna/software/miniforge3/envs/conda_R/lib/R"
        },
        "r.alwaysUseActiveTerminal": false,
        "r.sessionWatcher": true
    }
    

    Of note, this time around, I didn't mix conda and renv. Thus, conda is managing all R packages.

  10. yangqi-su commented on Jun 6, 2025

    @yangqi-su

    Same issue even now, no matter how I get on the compute nodes, the only R session it would attach to is on the login node.

  11. ThomasSoeiro commented on Sep 23, 2026

    @ThomasSoeiro
    Collaborator

    There are many similar issues is the repo, often related to remote access, conda and/or SSH. Please have a look and let us know if you can reproduce with correct configration and vscode-r 3.0.0-rc.0.

    @eitsupi @Fred-Wu @grantmcdermott perhaps it can be closed as not reproducible/obsolete?

  12. eitsupi commented on Sep 23, 2026

    @eitsupi
    Member

    Closing in favor of #1763

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions