Connection to interactive servers

CC-IN2P3 provides two interactive clusters to prepare tasks before they are submitted to the computing platform: development, test, etc.

The first one is and is intended to be used for the current usage, the second one is and provides a large memory capability.

Interactive servers are accessible with the following syntax:

% ssh -Y


% ssh -Y
  • and is an alias that redirects to the least loaded server of the cluster.

  • For Microsoft Windows users we recommend the use of PuTTY as an SSH client.

For more information on your connection to the CC-IN2P3 servers please refer to the following pages

Usage best practices

As each interactive server is shared by multiple users, we recommend a number of good practices to follow so that your activities can coexist with the other users activities.


Non compliance with these rules may result in some of your processes termination.

  • Only one computing process is allowed per interactive server and 3 processes over the entire interactive platform.

    • 24 hours maximum CPU time for a process and 1 hour CPU time for a multi-core process.

    • Inactive processes for more than 24 hours are killed.

  • Parallel processes with intensive use of both CPU and input/output are not allowed (example: make -j, scons, b2, ninja, etc.). However, it is possible to run such processes as interactive jobs (see interactive jobs).

  • Avoid excessive memory consumption that could have an impact on the system, if large memory usage is required, please switch to the ccahm cluster . The command htop -u username may be a useful monitoring tool.

  • It is forbidden to run tasks in “batch” mode (eg: processing a large amount of files in loop).

  • /scratch is not a permanent storage space: data can be deleted at any time to free up space. Under normal circumstances data is deleted after 14 days. Also, avoid large data storage.

  • One transfer process is allowed per server (example: scp, rsync or dq2-get) and 3 processes across all interactive servers.

  • Detached and persistent processes after logout are not allowed (excepted when using Screen).

    • Please note that Screen is neither meant as a substitute to the batch system, or as a way to run services nor as a way to hog scarse resources (like GPU interactive computing nodes).

    • Usage of Visual Studio Code

  • To preserve user data confidentiality, rmate (or other similar editor) requires using a random TCP port instead of a fixed port.

Usage of Visual Studio Code

If the internet connection on your workstation may be interrupted by your screen standby (the case of Mac users with a Thunderbolt connexion, i.e.: a connection to the Ethernet network wired on the screen), your VS Code windows will be closed due to the lack of connection. Below is the description of what is happening:

  • VS Code creates an SSH connection to a cca server and launches (on the interactive) Node.js,

  • the user temporarily interrupts his activity,

  • the workstation detects the lack of activity and puts the screen on standby: the network is disconnected:

    • the SSH connection disappears,

    • but VS Code’s Node.js persists!

    • the ghost VS Code is detected by the interactives monitoring (and killed).

On the other hand, and by default upon startup, VS Code looks for the names of the symbols in the source code for its auto-completion functions. For this purpose, it uses ripgrep which uses all the cores of the machine to do a quick scan.

It is recommended, if possible, to disable this collection with ripgrep (or to configure it to be less aggressive) to avoid too much load on the interactive server.