9 Process Management
RStudio Connect launches R to perform a variety of tasks. This includes:
- Installation of R packages
- Rendering of R Markdown documents
- Running Shiny Applications
- Running a Shiny application to customize a parameterized R Markdown document.
The location of R defaults to whatever is in the path. Customize the
Server.RVersion setting to use a specific R installation. See Chapter 11 for details.
The RStudio Connect process runs as the
root user. It needs escalated privileges to allow binding to protected ports and to create “unshare” environments that contain the R processes.
RStudio Connect runs its R processes as an unprivileged user; both a system default and content-specific overrides are supported. See Section 9.3 for details.
The “unshare” environment created for R execution involves first establishing a number of bind mounts and then switching to the target unprivileged user. RStudio Connect uses
unshare to alter the execution context available to R processes. Within this newly established environment, a number of
mount calls are made in order to hide or isolate parts of the filesystem.
The following locations are masked during R execution:
Server.DataDirdirectory containing all variable data used by RStudio Connect.
Database.Dirdirectory, which can optionally be placed outside the data directory.
- Configuration directories, including
The following information is exposed during R execution:
packratdata directory (read-only except when installing packages).
Rdata directory (only when installing packages).
- The directory containing the unpackaged R code (Shiny and R Markdown).
- The document rendering destination directory (only for R Markdown).
- A per-process temporary directory (exposed over the original
Applications.HomeMounting is enabled, the contents of
/home are masked by an additional bind mount as follows:
- The contents of
/homeare masked by the home directory of the
- If the
RunAsdoes not have a home directory, an empty directory masks
The path to the home directory is always available through the
HOME environment variable. With
Applications.HomeMounting, the mounted path to the
HOME directory is subject to change. Avoid hard-coding paths to either
Shiny applications have write access to the directory containing the unpackaged R code. This application directory is the working directory when launching Shiny. Data written here will be visible to all processes associated with that Shiny application but are not visible to other R processes. Application directory data remains available until that application is next deployed to RStudio Connect. A deployment creates a new application directory containing only the deployed content.
RStudio Connect may launch multiple processes to service requests for an application. There is no coordination between these processes. Shiny applications that write to local files could experience problems when different processes attempt to write to a single file. We recommend against using the file system for data persistence.
R Markdown documents have write access to the rendering destination directory and read access to a directory containing the unpackaged R code. The source directory is the working directory when calling
rmarkdown::render. The destination directory is passed as the
output_dir while a temporary directory is passed as the
intermediates_dir. The intermediate directory is transient and not available after rendering completes. A new output directory is created whenever the document is rendered. Data created during one rendering is not visible to another.
R Markdown multi-document sites have a slightly different rendering pipeline than standalone documents. RStudio Connect uses the
rmarkdown::render_site function, which does its rendering in-place. The content from the source directory is copied into the rendering destination directory in preparation for rendering. Site rendering has write access to the destination directory. Access to the original source directory is not provided because the source content is duplicated in the destination directory
rmarkdown::render_site call usually places its output into a subdirectory (typically, ’_site’). The contents of this output subdirectory will be moved to the root of the rendering destination directory, replacing any other content. No post-rendering file movement occurs if
rmarkdown::render_site is instructed to render into the current directory instead of a subdirectory. This means that both source and output files will be available for serving.
We recommend against configuring
rmarkdown::render_siteto write its output into the current directory. Rendering the site into a subdirectory (the default) allows RStudio Connect to remove source from the output directory.
RStudio Connect serves rendered content from the document output directory. This content remains available until a subsequent rendering is successful and activated (if requested). Neither incomplete nor unsuccessful document renderings affect the availability of previously rendered content.
9.2 Shiny Applications
Most of the R processes started by RStudio Connect are batch-oriented tasks. R is invoked, does a narrow set of work, and then exits. Shiny applications are different and may see an R process handle many requests for many users over its lifetime.
RStudio Connect launches an R process tied to a Shiny application when the first request arrives for that application. That R process will continue to service requests until it becomes idle and eventually terminated. If there is sufficient traffic against that Shiny application, RStudio Connect may launch additional processes to service those requests.
There are a number of configuration parameters which control the conditions under which processes for Shiny applications are launched and eventually reaped. The default values are appropriate for most applications but occasionally need customization in specialized environments. Section 15.13 explains each of the options.
We recommend that adjustment to these runtime properties be done gradually.
9.3 User Account for R Processes
The RStudio Connect installation creates a local
rstudio-connect user account. This account runs all the R processes;
root does not invoke R. If you would like a different user to run R, customize the
Administrators can customize the
RunAs user on a content-specific level. This means that different Shiny applications and R Markdown reports can be run using different Unix accounts. This setting can be found on the Access tab when editing content settings. Publishers and Viewers are prohibited from changing the
RunAs user on a content-specific level.
If you choose to specify a custom
RunAs user for content, that user must be a member of the Unix group that is the primary group of the default
rstudio-connectuser, for example, has a primary group also named
rstudio-connect. Any Unix account configured as a custom
RunAsuser for a Shiny application or R Markdown report must be a member of the
Installation of R packages always happens as the
Application.RunAs user. A Shiny application or R Markdown report may override its
RunAs setting; this alters how the deployed code is executed and does not impact package installation. See Section 9.1 for more information about process sandboxing.
9.4 PAM sessions
RStudio Connect can use PAM to establish the environment and resources available for R sessions.
See Section 7.5 for information about using PAM for user authentication.
PAM sessions are enabled with the
[PAM] UseSession = true
The default PAM service name used for PAM sessions is
su. This gives RStudio Connect the ability to launch processes as the specified user without requiring a password.
You can customize the PAM service name used for PAM sessions by customizing the
[PAM] SessionService = rstudio-connect-session
Any custom PAM service must contain the PAM directive that enables authentication with root privilege.
# Allows root to su without passwords (required) auth sufficient pam_rootok.so
9.5 Path Rewriting
The sandboxing used by RStudio Connect involves bind mounts which map physical locations on disk onto different directory structures at runtime. Paths used by your R code use these sandboxed locations. If you need to find the physical file on disk, you will need to undo the path transformation.
This section gives some examples of path rewriting and offer some ways of finding the file you need.
Let’s start with an
app.R file that describes a Shiny application. This file will be in the
apps/XX/YY/ directory underneath the
Server.DataDir location. The
YY path components correspond to the application ID and bundle (or deployment) ID for this version of your application. This directory is available at runtime as
The directory structure of
/opt/rstudio-connect/mnt/ is just a number of empty directories. The “unshare” environment created during sandboxing allows RStudio Connect to associate different application directories with these mount directories.
Here are some common path transformations that may be helpful. All of the physical paths are beneath the
Server.DataDir hierarchy that defaults to
/var/lib/rstudio-connect. All of the sandbox paths are beneath the mount directory
/opt/rstudio-connect/mnt/. This location is not customizable.
|Physical path||Sandbox path|
Here are some actual path transformations using the default
# A source Shiny application /var/lib/rstudio-connect/apps/4/7/app.R => /opt/rstudio-connect/mnt/app/app.R # A source R Markdown document /var/lib/rstudio-connect/apps/8/12/index.Rmd => /opt/rstudio-connect/mnt/app/index.Rmd # An HTML document rendered from that R Markdown document /var/lib/rstudio-connect/reports/8.2/index.html => /opt/rstudio-connect/mnt/report/index.html # A staticly deployed document /var/lib/rstudio-connect/apps/17/21/index.html => /opt/rstudio-connect/mnt/app/index.html # The Shiny package inside the packrat cache /var/lib/rstudio-connect/packrat/3.2.5/v2/library/shiny/ 28d6903a44dc53bd4823fa43ccdc08e5/shiny => /opt/rstudio-connect/mnt/packrat/3.2.5/v2/library/shiny/ 28d6903a44dc53bd4823fa43ccdc08e5/shiny
9.6 Program Supervisors
You may need to modify the environment or resources available to R processes prior to R being launched. This can be accomplished using a program supervisor using the
Applications.Supervisor configuration setting.
The supervisor command is provided the full R command-line, which MUST be invoked by the supervisor. The process exit code from R MUST be returned as the exit code of the supervisor. The file descriptors for standard input, output, and error MUST NOT be intercepted by the supervisor.
A supervisor is executed as the appropriate
RunAs user. Package installation always uses the
Applications.RunAs user. Other R processes will use the content-specific
RunAs account, falling back to
Applications.RunAs if no override was configured. See Section 9.3 for details.
Supervisors run within the sandbox established for any R process. See Section 9.1 for more information about process sandboxes.
RStudio Connect configures the
RSTUDIO_PANDOC environment variables for launched R processes. RStudio Connect also manages package installation and references. Avoid altering any of this behavior in program supervisors.
9.6.1 Example Supervisors
Here is a configuration that uses the
nice command to lower the priority of all R processes. See http://linux.die.net/man/1/nice for details about
nice. Because process supervisors are run as a
RunAs user and not as
root or another super-user, you may not be permitted to assign a negative (higher priority) privilege.
[Applications] Supervisor = nice -n 2
Here is a configuration that uses a custom script to prepare a custom execution environment before finally running R.
[Applications] Supervisor = /some/script/that/prepares/an/environment.sh
Here is an example supervisor that echos its arguments, sets an environment variable, then invokes whatever arguments have been passed.
#!/bin/bash echo arguments: "$@" echo export COMPANY_DATA_HOME="/data/resides/here" exec "$@"
Your organization may use shell initialization scripts to establish a particular environment. This environment might not be completely compatible with how RStudio Connect attempts to launch R.
We recommend building supervisor scripts gradually and carefully. Changes to the environment can alter how your content executes or even prevent R from running correctly.