Versions Compared

Version Old Version 11 New Version Current
Changes made by

Christopher Creswell

Christopher Creswell

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Motivation and intended usage:

...

To get an RStudio Server in the kubernetes cluster, you go to https://kubeportal.cc.lehigh.edu, then click on the "Class Apps" dropdown menu along the top of the page and selects select "RStudio server (kubernetes)" for the generic RStudio instance in kubernetes, or the particular application for your course if applicable (a course can get its own entry here if it maps a network shared drive that is specific to the course).  You are brought to a form where you can select the version of R that you want, and then you can click the "Launch" button.  It takes a minute or two for the instance to start, and then a "Connect to RStudio Server" button appears that takes you to your RStudio instance.

...

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.

...

Click the "Stop My Server" button and wait a minute or two - the screen will change on its own.  The "Stop My Server" button will disappear and there will be one button saying "Start My Server".  Press that and you will be presented with the environment selection menu again, and you'll be able to start a new instance.  You can also access this screen to start/stop your JupyterLab instance from a running instance in the File menu by choosing "Hub Control Panel":


If that doesn't help, then the problem will likely require some work at the back-end to fix.  Please put in a ticket for the Systems Engineering Team at https://jira.cc.lehigh.edu/servicedesk/customer/portal/1/create/200 and we'll look into the issue. 

When submitting the ticket, please mention JupyterHub in the title.  Please include the following information in the ticket details:

  • 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.