Motivation and intended usage:

...

The following error in RStudio is harmless:

2022-01-26T20:04:48.938685Z [rsession-<username>] WARNING No memory control group found in /proc/self/cgroup; LOGGED FROM: std::__cxx11::string rstudio::core::system::{anonymous}::getMemoryCgroup() src/cpp/core/system/LinuxResources.cpp:335

It shows up on starting an RStudio Server session.  We have not yet found a way to prevent it from happening.  The error is related to a version mismatch between kubernetes, the container engine it's using to run RStudio, and the OS running both.  It should eventually go away when we are able to upgrade everything to use the same version of "cgroups", which are used to control the resources granted to containers.  Everything will still work fine in spite of this error.

...

Upon using the "plot" function in RStudio, this error may appear:

Warning message:
In grSoftVersion() :
  unable to load shared object '/usr/local/lib/R/modules//R_X11.so':
  libXt.so.6: cannot open shared object file: No such file or directory

This is also harmless - the plot function still works.  The error is caused by the way the container was built - the RStudio images are based on the Rocker project (https://www.rocker-project.org/ ) and this is related to the way they built the image.  An update to the image would fix it - we'll raise an issue in the Rocker project's github to make sure they are aware of it.

...

• The device you're using (laptop, desktop, tablet)
• OS you're using (Mac/Windows/Linux/iOS/Android/whatever else) and what version you have
• Browser you're using (Chrome/Firefox/Safari/Edge) and what version you have
• Your location - on-campus or off-campus with VPN
• The error message you saw
  • A screenshot if possible
• The name of the file you were editing in your JupyterLab instance
• What time the error occurred (helpful for narrowing down searches of the application's logs)
• (Optional) You can also check the browser's "Developer Tools" console to see any errors your browser has received that may not be displayed, and include that in the ticket.

In the past, the following have occasionally caused problems:

• Code that writes a ton of output to a cell
  • All the output of your code in JupyterLab is written directly into the .ipynb file, so if you have too much output, it can cause JupyterLab to crash when trying to open or save the file.  To avoid this, don't have your code print out every line of a thousand line long input file, and be sure to clear output cells if you do print out a bunch of data.
• Attempting to export and convert notebook files to PDF/HTML when they contain special characters in code or output
  • The conversion process can be finicky.  There's not much we can do about this other than recommend trying a different format, and making sure your output is plain ASCII characters.