RStudio Server proporciona un entorno de desarrollo integrado para R accesible desde un navegador web. Permite trabajar con la consola de R, editar código, gestionar proyectos, visualizar gráficos, instalar y cargar paquetes y utilizar las herramientas habituales de RStudio sin necesidad de instalar el IDE en el equipo local.
0.42024.12.0+4674.4.2foss/2024aLa instalación se encuentra en el árbol jerárquico de módulos asociado a GCC 13.3.0 y OpenMPI 5.0.3.
Para consultar los requisitos exactos de carga:
module load rama0.4
module spider RStudio-Server/2024.12.0+467-R-4.4.2
En la instalación actual puede cargarse mediante:
module load rama0.4 \
GCC/13.3.0 \
OpenMPI/5.0.3 \
RStudio-Server/2024.12.0+467-R-4.4.2
Si module spider no encuentra una instalación reciente, comprobar sin utilizar la caché:
module --ignore_cache spider RStudio-Server
Después de cargar el módulo pueden comprobarse los ejecutables disponibles:
command -v rserver
command -v rsession
command -v R
R --version
module list
Para consultar la versión instalada puede leerse el archivo VERSION de la instalación:
cat /lustre/opt/foss/0.4/software/RStudio-Server/2024.12.0+467-foss-2024a-R-4.4.2/VERSION
En esta compilación, rserver --version devuelve unrecognised option.
La carga del módulo no inicia RStudio Server. El comando rserver inicia un servicio web y, en un clúster gestionado por SLURM, debe ejecutarse dentro de los recursos asignados a un trabajo.
Las páginas bajo server-pro describen Posit Workbench y pueden incluir funciones exclusivas de la edición comercial o de versiones posteriores. Esta guía utiliza RStudio Server Open Source 2024.12.0+467; no todas las opciones de esa referencia son aplicables.
RStudio Open Source se distribuye bajo la licencia
GNU Affero General Public License v3.
La licencia de RStudio no determina la licencia de los paquetes de R utilizados desde el entorno. Cada paquete puede estar sujeto a su propia licencia.
RStudio Server proporciona el servicio web mediante rserver, mientras que las sesiones de trabajo de R se ejecutan mediante rsession.
En Drago se recomienda ejecutar una instancia personal de RStudio Server dentro de un trabajo de SLURM. El servidor se inicia en el nodo de cálculo asignado y escucha únicamente en la interfaz de loopback del propio nodo:
127.0.0.1
El acceso desde el ordenador del usuario se realiza mediante un túnel SSH pasando por el nodo de acceso. De esta forma, el puerto de RStudio Server no se publica directamente en la red del clúster.
El flujo general es:
sbatch.rserver dentro del nodo asignado.Importante: mientras el trabajo de SLURM esté activo, los recursos solicitados permanecen reservados aunque no se esté utilizando activamente la interfaz web.
El siguiente procedimiento inicia una instancia personal de RStudio Server en un nodo normal de cómputo, sin privilegios de administrador. Solicita 8 CPU, 32 GiB de memoria y 4 horas en generic; estos valores deben ajustarse a las necesidades del trabajo y a los límites de la cuenta y partición.
El script utiliza module, curl, ss y las utilidades habituales de Linux. Supone que /tmp es almacenamiento local del nodo y permite ejecutar el auxiliar de autenticación. Si la política de Drago establece otra ubicación temporal local, debe sustituirse la ruta usada por mktemp.
Cada trabajo genera una contraseña aleatoria para RStudio. No se solicita entrada interactiva dentro de sbatch. La contraseña se guarda en un archivo privado y no se imprime en los registros de SLURM.
rstudio_server.sbatch#!/bin/bash
#SBATCH --job-name=rstudio
#SBATCH --nodes=1
#SBATCH --ntasks=1
#SBATCH --cpus-per-task=8
#SBATCH --mem=32G
#SBATCH --time=04:00:00
#SBATCH --partition=generic
#SBATCH --output=rstudio-%j.out
#SBATCH --error=rstudio-%j.err
set -euo pipefail
umask 077
module load rama0.4 \
GCC/13.3.0 \
OpenMPI/5.0.3 \
RStudio-Server/2024.12.0+467-R-4.4.2
for executable in rserver R curl ss; do
command -v "$executable" >/dev/null || {
printf 'No se encuentra el ejecutable: %s\n' "$executable" >&2
exit 1
}
done
# Limitar bibliotecas auxiliares al número de CPU concedidas.
export OMP_NUM_THREADS="${SLURM_CPUS_PER_TASK}"
export OPENBLAS_NUM_THREADS="${SLURM_CPUS_PER_TASK}"
export MKL_NUM_THREADS="${SLURM_CPUS_PER_TASK}"
export NUMEXPR_NUM_THREADS="${SLURM_CPUS_PER_TASK}"
R_EXECUTABLE="$(command -v R)"
R_HOME="$("$R_EXECUTABLE" RHOME)"
export R_HOME
export R_DOC_DIR="$R_HOME/doc"
LOGIN_USER="$(id -un)"
NODE_NAME="$(hostname -s)"
RSTUDIO_PORT="${RSTUDIO_PORT:-$((20000 + SLURM_JOB_ID % 30000))}"
if ! [[ "$RSTUDIO_PORT" =~ ^[1-9][0-9]{3,4}$ ]] ||
(( RSTUDIO_PORT < 1024 || RSTUDIO_PORT > 65535 )); then
printf 'Puerto no válido: %s (debe estar entre 1024 y 65535).\n' "$RSTUDIO_PORT" >&2
exit 1
fi
# La fórmula reduce coincidencias, pero no reserva el puerto.
listeners="$(ss -H -ltn "sport = :${RSTUDIO_PORT}")"
if [[ -n "$listeners" ]]; then
printf 'Puerto remoto ocupado: %s. Reenviar con otro RSTUDIO_PORT.\n' "$RSTUDIO_PORT" >&2
exit 1
fi
BASE_DIR="$HOME/.rstudio-server"
SESSION_DIR="${BASE_DIR}/sessions/${SLURM_JOB_ID}"
SESSION_FILE="${BASE_DIR}/rstudio-${SLURM_JOB_ID}.info"
INFO_TMP="${SESSION_FILE}.tmp"
# Estado del IDE y registros persistentes; directorios privados.
mkdir -p "${SESSION_DIR}/data" "${SESSION_DIR}/log"
chmod 700 "$BASE_DIR" "${BASE_DIR}/sessions" "$SESSION_DIR"
rm -f -- "$SESSION_FILE" "$INFO_TMP"
# SQLite, sockets, configuración y claves en almacenamiento local del nodo.
RUNTIME_DIR="$(mktemp -d "/tmp/rstudio.${SLURM_JOB_ID}.XXXXXX")"
rserver_pid=''
cleanup() {
status=$?
trap - EXIT INT TERM
set +e
if [[ -n "$rserver_pid" ]] && kill -0 "$rserver_pid" 2>/dev/null; then
kill "$rserver_pid" 2>/dev/null
wait "$rserver_pid" 2>/dev/null
fi
rm -f -- "$SESSION_FILE" "$INFO_TMP"
rm -rf -- "$RUNTIME_DIR"
exit "$status"
}
trap cleanup EXIT
trap 'exit 130' INT
trap 'exit 143' TERM
mkdir -p "$RUNTIME_DIR"/{database,server-data,config,cache}
export RSTUDIO_CONFIG_DIR="$RUNTIME_DIR/config"
export XDG_DATA_HOME="$SESSION_DIR/data"
export XDG_CACHE_HOME="$RUNTIME_DIR/cache"
export RS_LOG_DIR="$SESSION_DIR/log"
printf 'provider=sqlite\ndirectory=%s\n' \
"$RUNTIME_DIR/database" > "$RUNTIME_DIR/database.conf"
# Secreto distinto para cada trabajo; no activar trazas con set -x.
RSTUDIO_PASSWORD="$(od -An -N24 -tx1 /dev/urandom | tr -d ' \n')"
export RSTUDIO_PASSWORD
cat > "$RUNTIME_DIR/auth" <<'AUTH'
#!/bin/bash
IFS= read -r supplied_password || true
[[ -n ${RSTUDIO_PASSWORD:-} &&
${1:-} == "$(id -un)" &&
"$supplied_password" == "$RSTUDIO_PASSWORD" ]]
AUTH
chmod 700 "$RUNTIME_DIR/auth"
rserver \
--config-file=/dev/null \
--server-daemonize=0 \
--server-user="$LOGIN_USER" \
--www-address=127.0.0.1 \
--www-port="$RSTUDIO_PORT" \
--auth-none=0 \
--auth-encrypt-password=0 \
--auth-pam-helper-path="$RUNTIME_DIR/auth" \
--rsession-which-r="$R_EXECUTABLE" \
--database-config-file="$RUNTIME_DIR/database.conf" \
--server-data-dir="$RUNTIME_DIR/server-data" \
--server-pid-file="$RUNTIME_DIR/rserver.pid" \
--secure-cookie-key-file="$RUNTIME_DIR/secure-cookie-key" &
rserver_pid=$!
# RUNNING en SLURM no implica que el servicio web esté preparado.
ready=0
for (( attempt=0; attempt<60; attempt++ )); do
if ! kill -0 "$rserver_pid" 2>/dev/null; then
printf 'rserver terminó durante el arranque. Revisar .err y los registros.\n' >&2
exit 1
fi
http_code="$(curl --noproxy '*' --silent --output /dev/null \
--write-out '%{http_code}' --max-time 1 \
"http://127.0.0.1:${RSTUDIO_PORT}/" || true)"
case "$http_code" in
200|302|303)
# Confirmar que el proceso propio sigue vivo tras la respuesta.
if kill -0 "$rserver_pid" 2>/dev/null; then
ready=1
break
fi
;;
esac
sleep 1
done
if (( ready == 0 )); then
printf 'RStudio no respondió a tiempo. Revisar .err y los registros.\n' >&2
exit 1
fi
# Publicar los datos de conexión solo después de comprobar el servicio.
cat > "$INFO_TMP" <<EOF
SLURM_JOB_ID=${SLURM_JOB_ID}
NODE_NAME=${NODE_NAME}
RSTUDIO_PORT=${RSTUDIO_PORT}
RSTUDIO_USER=${LOGIN_USER}
RSTUDIO_PASSWORD=${RSTUDIO_PASSWORD}
R_EXECUTABLE=${R_EXECUTABLE}
SESSION_DIR=${SESSION_DIR}
RUNTIME_DIR=${RUNTIME_DIR}
EOF
chmod 600 "$INFO_TMP"
mv -f -- "$INFO_TMP" "$SESSION_FILE"
cat <<EOF
RStudio Server preparado (comprobación HTTP superada)
Trabajo SLURM : ${SLURM_JOB_ID}
Nodo : ${NODE_NAME}
Puerto remoto : ${RSTUDIO_PORT}
R : ${R_EXECUTABLE}
Registros : ${SESSION_DIR}/log
Info privada : ${SESSION_FILE}
Desde el ordenador local:
ssh -N -o ExitOnForwardFailure=yes -J ${LOGIN_USER}@drago.csic.es -L 127.0.0.1:8787:127.0.0.1:${RSTUDIO_PORT} ${LOGIN_USER}@${NODE_NAME}
Abrir http://127.0.0.1:8787 e introducir el usuario y la contraseña del archivo .info.
Para finalizar el trabajo: scancel ${SLURM_JOB_ID}
EOF
# Mantener vivo el trabajo y conservar el código de salida de rserver.
server_status=0
wait "$rserver_pid" || server_status=$?
rserver_pid=''
exit "$server_status"
El archivo .info contiene una contraseña: no debe compartirse ni pegarse en incidencias sin eliminar ese campo. Los registros se conservan bajo $HOME/.rstudio-server/sessions/; los datos temporales del servidor se eliminan al terminar normalmente el script. Si SLURM fuerza una terminación con SIGKILL o falla el nodo, las trampas de limpieza no se ejecutan y pueden quedar archivos residuales. La existencia de .info por sí sola no confirma que el trabajo siga activo.
Desde el nodo de acceso:
sbatch rstudio_server.sbatch
SLURM mostrará un identificador de trabajo, por ejemplo:
Submitted batch job 123456
squeue -j 123456 \
-o "%.18i %.9P %.24j %.8T %.20N %.10M %.10l"
El estado debe ser RUNNING. Además, hay que esperar al mensaje RStudio Server preparado en el archivo .out y a que aparezca el archivo .info. La respuesta HTTP comprueba el servidor web; el inicio real de la sesión de R se comprueba al entrar en el navegador.
cat rstudio-123456.out
También se genera un archivo de sesión:
cat "$HOME/.rstudio-server/rstudio-123456.info"
La salida tendrá un formato similar a:
SLURM_JOB_ID=123456
NODE_NAME=drago31010022
RSTUDIO_PORT=23456
RSTUDIO_USER=usuario
RSTUDIO_PASSWORD=(contraseña aleatoria; no compartir)
R_EXECUTABLE=/lustre/opt/foss/0.4/software/R/4.4.2-gfbf-2024a/bin/R
SESSION_DIR=/lustre/home/usuario/.rstudio-server/sessions/123456
RUNTIME_DIR=/tmp/rstudio.123456.ABCDEF
Debe utilizarse el nodo y el puerto indicados para crear el túnel SSH. En los ejemplos siguientes, sustituir usuario, 123456, drago31010022 y 23456 por los valores reales. La ruta de $HOME depende de cada cuenta; el ejemplo no establece una ruta obligatoria.
El nodo de cálculo normalmente se alcanza pasando por el nodo de acceso:
drago.csic.es
Si el trabajo está ejecutándose en drago31010022 y RStudio escucha en el puerto 23456:
ssh -N -o ExitOnForwardFailure=yes \
-L 127.0.0.1:8787:127.0.0.1:23456 \
-J usuario@drago.csic.es \
usuario@drago31010022
La opción:
-L 127.0.0.1:8787:127.0.0.1:23456
conecta el puerto 8787 de la interfaz local del ordenador con el puerto 23456 de la interfaz local del nodo de cálculo, a través de SSH. El comando se ejecuta en el ordenador local, no en el nodo de acceso.
La opción -J utiliza drago.csic.es como jump host.
El proceso SSH debe permanecer activo mientras se utiliza RStudio. Que no aparezca un nuevo prompt es normal con -N.
ExitOnForwardFailure=yes detecta errores al establecer el reenvío, como un puerto local ocupado. No comprueba que RStudio siga escuchando en el extremo remoto.
Con el túnel abierto:
http://127.0.0.1:8787
Debe aparecer la pantalla de acceso de RStudio. Introducir:
RSTUDIO_USER del archivo .info.RSTUDIO_PASSWORD del mismo archivo.Es una contraseña temporal distinta de la contraseña de la cuenta del clúster. Cada trabajo nuevo genera otra. El auxiliar de autenticación permite únicamente el usuario que ha iniciado el servidor.
El script mantiene --auth-none=0. Escuchar en 127.0.0.1 limita el acceso de red, pero otros usuarios del mismo nodo también pueden conectarse a sus puertos locales. Por eso no debe desactivarse la autenticación en un nodo compartido.
La opción --auth-encrypt-password=0 se utiliza con el auxiliar de autenticación de esta instancia personal. El transporte entre el ordenador y el nodo está protegido por SSH; este procedimiento requiere mantener el servicio y el extremo local del túnel ligados a 127.0.0.1.
La clave privada utilizada para acceder a Drago debe permanecer en el ordenador local.
ssh-agentSi la sesión local ya dispone de un agente SSH, utilizarlo. Si no existe uno, iniciarlo:
eval "$(ssh-agent -s)"
Cargar la clave en ese agente:
ssh-add ~/.ssh/clave_privada
ssh-add -l
Estos comandos se ejecutan en el ordenador local. ProxyJump no necesita copiar la clave al clúster ni activar ForwardAgent.
Comprobar el acceso al nodo de entrada:
ssh usuario@drago.csic.es
Salir de esa sesión con exit para volver al ordenador local y abrir allí el túnel:
ssh -N -o ExitOnForwardFailure=yes \
-L 127.0.0.1:8787:127.0.0.1:23456 \
-J usuario@drago.csic.es \
usuario@drago31010022
-issh \
-i ~/.ssh/clave_privada \
-o IdentitiesOnly=yes \
-o 'ProxyCommand=ssh -i ~/.ssh/clave_privada -o IdentitiesOnly=yes -W %h:%p usuario@drago.csic.es' \
-N -o ExitOnForwardFailure=yes \
-L 127.0.0.1:8787:127.0.0.1:23456 \
usuario@drago31010022
~/.ssh/configHost drago
HostName drago.csic.es
User usuario
IdentityFile ~/.ssh/clave_privada
IdentitiesOnly yes
Host drago3*
User usuario
IdentityFile ~/.ssh/clave_privada
IdentitiesOnly yes
ProxyJump drago
Después:
ssh -N -o ExitOnForwardFailure=yes \
-L 127.0.0.1:8787:127.0.0.1:23456 \
drago31010022
El puerto local no tiene que coincidir con el puerto remoto.
ssh -N -o ExitOnForwardFailure=yes \
-L 127.0.0.1:8788:127.0.0.1:23456 \
-J usuario@drago.csic.es \
usuario@drago31010022
En ese caso debe abrirse:
http://127.0.0.1:8788
No es necesario reiniciar el trabajo de SLURM.
El script selecciona el ejecutable R disponible tras cargar los módulos y lo fija explícitamente:
--rsession-which-r="$R_EXECUTABLE"
donde se establece:
R_EXECUTABLE="$(command -v R)"
R_HOME="$("$R_EXECUTABLE" RHOME)"
export R_HOME
export R_DOC_DIR="$R_HOME/doc"
De esta forma, la sesión utiliza la versión de R proporcionada por el módulo cargado.
Desde la consola de RStudio:
R.version.string
R.home()
.libPaths()
sessionInfo()
Para esta instalación debe utilizarse R 4.4.2.
Desde la terminal integrada:
command -v R
R --version
El procedimiento inicia RStudio con el entorno creado por los módulos de EasyBuild. Las rutas efectivas deben comprobarse dentro de la consola de R, ya que los archivos de inicio del usuario pueden modificarlas.
Para consultar las bibliotecas:
.libPaths()
Localizar un paquete:
find.package("ggplot2")
Consultar su versión:
packageVersion("ggplot2")
Consultar la biblioteca personal:
Sys.getenv("R_LIBS_USER")
No se recomienda modificar manualmente las bibliotecas centrales instaladas bajo:
/lustre/opt/foss/0.4/software/
Los paquetes personales deben instalarse en ubicaciones escribibles por el usuario.
Los recursos disponibles para la sesión son los concedidos por SLURM.
En el ejemplo:
#SBATCH --cpus-per-task=8
El script también define:
export OMP_NUM_THREADS="${SLURM_CPUS_PER_TASK}"
export OPENBLAS_NUM_THREADS="${SLURM_CPUS_PER_TASK}"
export MKL_NUM_THREADS="${SLURM_CPUS_PER_TASK}"
export NUMEXPR_NUM_THREADS="${SLURM_CPUS_PER_TASK}"
Estas variables limitan las bibliotecas que las respetan, aunque determinados paquetes pueden utilizar mecanismos propios de paralelización.
Desde R:
Sys.getenv("SLURM_CPUS_PER_TASK")
Para fijar explícitamente el número de trabajadores:
nworkers <- as.integer(Sys.getenv("SLURM_CPUS_PER_TASK", "1"))
parallel::detectCores() puede mostrar todos los procesadores visibles en el nodo y no necesariamente el límite asignado al trabajo.
Evitar multiplicar procesos por hilos sin ajustar los límites: por ejemplo, 8 trabajadores que ejecuten cada uno una BLAS de 8 hilos pueden intentar utilizar 64 hilos. Cuando se utilice paralelismo por procesos, valorar fijar las bibliotecas auxiliares a un hilo por trabajador.
La memoria reservada se establece mediante:
#SBATCH --mem=32G
Debe dimensionarse en función de los datos, objetos de R, operaciones intermedias y procesos paralelos.
Desde el nodo de acceso, sustituir el identificador del ejemplo para consultar las estadísticas disponibles durante el trabajo:
sstat -j 123456.batch \
--format=JobID,AveCPU,MaxRSS,AveRSS
Y el estado final mediante:
sacct -j 123456 \
--format=JobID,JobName,State,ExitCode,Elapsed,AllocCPUS,ReqMem,MaxRSS
SLURM_JOB_ID se define dentro del trabajo, pero no necesariamente en una sesión independiente en el nodo de acceso. MaxRSS es una medida de contabilidad por tarea/paso, no una suma fiable de todos los procesos de R; puede aparecer vacía si no se han recogido esos datos.
RStudio Server no necesita una GPU para proporcionar la interfaz web.
Si el código de R necesita GPU, el trabajo debe solicitarla expresamente. Si la partición y el recurso siguientes están disponibles para la cuenta, sustituir #SBATCH --partition=generic por #SBATCH --partition=gpu y añadir la petición de GPU:
#SBATCH --partition=gpu
#SBATCH --gres=gpu:1
Puede comprobarse la GPU asignada con:
nvidia-smi
Ejecutar RStudio en un nodo GPU no hace que R utilice automáticamente la GPU. El paquete o biblioteca utilizado debe disponer de soporte específico para aceleración GPU y del entorno CUDA u otras dependencias que requiera.
RStudio puede acceder a los sistemas de archivos montados en el nodo con los permisos del usuario, por ejemplo:
$HOME
/lustre/home/...
/lustre/...
En este procedimiento, SQLite y los archivos de ejecución del servidor se guardan bajo /tmp/rstudio.<jobid>.*, en el nodo asignado. El estado del IDE y los registros quedan bajo $HOME/.rstudio-server/sessions/<jobid>/. Son directorios distintos para cada trabajo: no se garantiza la reanudación automática de una sesión anterior ni de sus preferencias.
Los proyectos y datos deben guardarse en ubicaciones persistentes. Los archivos almacenados únicamente en /tmp o en almacenamiento temporal del nodo pueden desaparecer cuando termine el trabajo.
Una vez abierta la interfaz web puede crearse un proyecto mediante:
File -> New Project
También puede abrirse un proyecto existente a partir de su archivo .Rproj.
Cerrar el trabajo de SLURM termina la sesión de RStudio, pero no elimina los archivos guardados en $HOME o Lustre.
La terminal de RStudio se ejecuta dentro del mismo nodo reservado por SLURM.
Puede comprobarse:
hostname
echo "$SLURM_JOB_ID"
echo "$SLURM_CPUS_PER_TASK"
module list
Guardar los archivos y resultados necesarios antes de cancelar. Cerrar el navegador o el túnel SSH no libera los recursos del trabajo.
Desde el nodo de acceso:
scancel 123456
También debe cerrarse el proceso del túnel SSH en el ordenador local mediante Ctrl+C.
Si se alcanza el tiempo solicitado mediante #SBATCH --time, SLURM finalizará automáticamente el trabajo y la interfaz web dejará de responder.
Comprobar:
squeue -j 123456
cat rstudio-123456.out
cat rstudio-123456.err
Consultar el nodo:
squeue -j 123456 -o "%.18i %.8T %.20N"
El túnel debe apuntar exactamente a ese nodo.
Dentro del nodo de cálculo que ejecuta el trabajo, utilizar el puerto real del archivo .info. Por ejemplo:
RSTUDIO_PORT=23456
ss -ltn "sport = :${RSTUDIO_PORT}"
curl --noproxy '*' --silent --show-error --output /dev/null \
--write-out 'HTTP %{http_code}\n' --max-time 5 \
"http://127.0.0.1:${RSTUDIO_PORT}/"
Una respuesta 200 o una redirección 302/303 indica que existe respuesta HTTP; no verifica todavía la autenticación ni que R haya arrancado. La variable RSTUDIO_PORT del script no aparece automáticamente en otra sesión SSH.
Si responde dentro del nodo pero no desde el navegador local, debe revisarse el túnel SSH.
ssh -vvv -N -o ExitOnForwardFailure=yes \
-L 127.0.0.1:8787:127.0.0.1:23456 \
-J usuario@drago.csic.es \
usuario@drago31010022
Comprobar que el trabajo está RUNNING, el nodo coincide con el asignado, el puerto es correcto y la clave privada está disponible.
Permission denied (publickey,...)ssh-add -l
Si el agente funciona pero no hay una clave cargada:
ssh-add ~/.ssh/clave_privada
Si no se puede contactar con ningún agente, iniciarlo como se indica en la sección de autenticación SSH.
channel ... connect failed: Connection refusedSSH ha recibido una petición por el túnel, pero no consigue conectar al destino 127.0.0.1:puerto desde el nodo final. Normalmente no hay ningún servicio escuchando en ese puerto: comprobar el nodo, el puerto, los registros y que el trabajo siga activo. ExitOnForwardFailure=yes no evita este error.
El aviso de OpenSSH sobre el intercambio de claves poscuántico es independiente de este rechazo de conexión; no indica por sí mismo que el túnel haya fallado.
La fórmula basada en el identificador de trabajo no garantiza un puerto libre. Si el script informa de una colisión, reenviarlo con otro puerto remoto:
sbatch --export=ALL,RSTUDIO_PORT=23457 rstudio_server.sbatch
Consultar el nuevo archivo .info y usar su puerto en el túnel. La comprobación previa no reserva el puerto; también debe revisarse .err si otro proceso lo ocupa durante el arranque.
module load rama0.4
module --ignore_cache spider RStudio-Server
Si aparece al ignorar la caché, el problema es la actualización de la caché de Lmod. Utilizar el nombre y los módulos previos indicados por spider.
Revisar:
cat rstudio-123456.err
cat rstudio-123456.out
y los registros de la sesión:
ls -lah "$HOME/.rstudio-server/sessions/123456/log"
Para comprobar la carga básica de rsession, desde una asignación de SLURM y con los módulos anteriores cargados:
R_HOME="$(R RHOME)"
export R_HOME
export R_DOC_DIR="$R_HOME/doc"
rsession --verify-installation=1
printf 'Código de verificación: %s\n' "$?"
Un código 0 indica que esa comprobación ha terminado correctamente; no prueba el acceso por navegador ni sustituye a la prueba de una sesión completa.
Desde RStudio:
R.version.string
R.home()
Desde la terminal:
command -v R
R --version
El PATH de una terminal puede cambiar al leer sus archivos de inicio. Para identificar la versión de la sesión gráfica, prevalecen R.version.string y R.home() en la consola de RStudio.
.libPaths()
packageVersion("nombre_paquete")
Sys.getenv("R_LIBS")
Sys.getenv("R_LIBS_SITE")
Sys.getenv("R_LIBS_USER")
sacct -j 123456 \
--format=JobID,JobName,State,ExitCode,Elapsed,AllocCPUS,ReqMem,MaxRSS
Estados como OUT_OF_MEMORY, TIMEOUT o CANCELLED indican que debe revisarse el estado o los límites del trabajo.
Si aparece:
bind [127.0.0.1]:8787: Address already in use
utilizar otro puerto local:
ssh -N -o ExitOnForwardFailure=yes \
-L 127.0.0.1:8788:127.0.0.1:23456 \
-J usuario@drago.csic.es \
usuario@drago31010022
y abrir:
http://127.0.0.1:8788
Cada trabajo utiliza una base SQLite propia en $RUNTIME_DIR/database, dentro de /tmp en el nodo de cálculo. No ubicar esa base en $HOME cuando esté en Lustre ni en otro sistema de archivos compartido. La documentación de Posit advierte de problemas de integridad al usar SQLite sobre almacenamiento compartido.
Consultar RUNTIME_DIR en el archivo .info. En el nodo correspondiente, sustituir la ruta del ejemplo por la real:
RUNTIME_DIR=/tmp/rstudio.123456.ABCDEF
ls -ld "$RUNTIME_DIR" "$RUNTIME_DIR/database"
cat "$RUNTIME_DIR/database.conf"
df -h "$RUNTIME_DIR"
Si el arranque falló y ya terminó el trabajo, el directorio temporal puede haberse eliminado. Revisar primero rstudio-123456.err y los registros persistentes de la sesión.
Comprobar que se utiliza el usuario y la contraseña del trabajo actual, no la contraseña de SSH ni la de un trabajo anterior. Consultar el archivo privado:
cat "$HOME/.rstudio-server/rstudio-123456.info"
Comprobar también que el túnel apunta al nodo y puerto de ese mismo trabajo. No compartir el campo RSTUDIO_PASSWORD al solicitar asistencia.
El script conserva la autenticación de RStudio (--auth-none=0) y limita la escucha a --www-address=127.0.0.1. El cliente SSH también enlaza el puerto local explícitamente a 127.0.0.1.
La interfaz de loopback es compartida por los usuarios del mismo nodo; no proporciona aislamiento entre cuentas. Por tanto, no sustituir --auth-none=0 por --auth-none=1 en este procedimiento. Tampoco cambiar la escucha a 0.0.0.0 ni compartir el archivo de contraseña.
La contraseña aleatoria es propia de cada trabajo. La carpeta de sesión es privada y el archivo .info tiene permisos 600. El auxiliar valida esa contraseña y el usuario propietario; no modifica la configuración PAM del sistema ni la contraseña de la cuenta.
Desde la consola de R:
cat("R:", R.version.string, "\n")
cat("Home:", R.home(), "\n")
cat("Nodo:", Sys.info()[["nodename"]], "\n")
cat("Trabajo SLURM:", Sys.getenv("SLURM_JOB_ID"), "\n")
cat("CPU asignadas:", Sys.getenv("SLURM_CPUS_PER_TASK"), "\n")
print(.libPaths())
sessionInfo()
stopifnot(1 + 1 == 2)
library(ggplot2)
ggplot(mtcars, aes(wt, mpg)) + geom_point()
Desde la terminal integrada:
hostname
echo "$SLURM_JOB_ID"
echo "$SLURM_CPUS_PER_TASK"
command -v R
R --version
module list
La prueba debe mostrar R 4.4.2, el nodo y trabajo asignados, y el gráfico en el panel de gráficos. Comprobar además que se puede guardar y volver a abrir un archivo en el directorio persistente del proyecto.
Si el acceso web funciona pero faltan SLURM_JOB_ID o los límites de hilos dentro de R, revisar qué entorno conserva esta compilación de rsession y los archivos de inicio del usuario antes de ejecutar trabajo paralelo.
El uso recomendado de RStudio Server en Drago se divide en estos pasos:
rserver dentro del nodo, con autenticación y escucha en 127.0.0.1.drago.csic.es.http://127.0.0.1:8787 en el navegador e identificarse.RUNNING.scancel cuando ya no sea necesario.Los archivos guardados en $HOME o Lustre son persistentes. La sesión de RStudio y los recursos de cómputo existen únicamente mientras el trabajo de SLURM permanece activo.
rserver.confExitOnForwardFailure, reenvío local y ProxyJump