This article is focused on helping Administrators (Professors, TAs, graduate students, or LSIT staff) Troubleshoot. To follow these steps, you'll need to be a JupyterHub administrator. Normally this is done as part of the JupyterHub Request, or if an existing Administrator gives you access. 

Restarting Jupyter Server

Sometimes errors can occur if system files get overwritten, or corrupted by mistake or through something like a bad pip install. Since JupyterHub spins up a server from a container image, you can reset the state by deleting the container and re-deploying a fresh, unchanged container image.

First, be sure that you have attempted to contact the user and ensured that they have saved their files, since any unsaved work will be lost.

Next, head to the admin console:

Find the NetID of the student/user having trouble in the list and click on the "stop server" button. 

The button will change to "stopping" :

After that you can either allow the student/user to start their server on their own, or you can start a new container by clicking the now "start server" button. Any dependencies that aren't included in the container image will need to be re-installed. If there are dependencies that are needed for all students, we can include those in the default image. Just open a new support ticket here with the package name that is needed! 

Students/Users can start/stop their own containers by going to <instance>.lsit.ucsb.edu/hub/home where there will be a single button to stop or start the container. A second button will be available if it's already running and will take you to the default landing page. 

Troubleshooting Code

If a user is having trouble with code, or working inside a container, an administrator can access the server by impersonating that user. The "access server" button appears once a jupyter server is running. 

After clicking on it, you are then directed to the lab as the user. This allows you to run or test code, settings, commands, or scripts, without having to wait for a description. screenshots, or a copy and paste of errors or logs. Ultimately this can be a really powerful tool for admins to be able to determine what has been tried or done since they can go hands on with instance that the user is working with. This gets you to the root of issues quickly, then you can advise users more efficiently.

If you are unable to access the server, it's likely that it's become corrupted, and you can probably resolve that by restarting the server by following the steps in the previous section. If that fails to work, open a support ticket and our staff will assist you as soon as possible. 

RStudio 400 and 500 Error Codes

Occasionally user might try to run code that causes new packages to be installed, upgraded, or removed. Sometimes when this happens RStudio's cache is trying to load packages that no longer exist, or code that causes the instance to crash. This will normally result in 400 and 500 level codes while trying to use the RStudio endpoint (ie: https://<instance>.lsit.ucsb.edu/user/<NetID>/rstudio/) that might look something like this: 

The best way to clear these errors is by removing the folder that holds RStudio's cached information. You can do this with the following steps: 

• Open your instance to the lab landing page (https://<instance>.lsit.ucsb.edu/user/<NetID>/lab) 
• Launch a Terminal Instance
  
• From the terminal, move the directory that RStudio uses for cache by pasting in the following command:

  mv ~/.local/share/rstudio ~/.local/share/rstudio-backup

  This creates a new subfolder and RStudio will create a new one the next time it's launched. (It may take a few moments longer to load while it does this)
  
• Follow the steps above for Restarting Jupyter Server, and then re-open RStudio.