Content Comparison

...

System and JupyterHub server Python versions

After the Summer 2025 OS upgrade, the (single) Python kernel version in all JupyterHub servers is Python 3.12, and recent versions of many popular Python packages are available (e.g. pandas, numpy, scipy, etc.)

There are two versions of Python available on the command line ("system" Python) on BRCF compute servers. In Ubuntu 2024.04, these versions and the command commands to invoke them are:

• 2.7 - python, python2.7
• 3.812 - python3, python3.812

(Note that the Python 3.x python version on Ubuntu 18.04 was 3.6.)12 is the default version when you invoke python3. 

There are corresponding versions of pip that should be used to install 3rd party packages:

• for Python 2 - pip, pip2
• for Python 3.12 - pip3, pip3.12

Understanding Python add-on packages

Globally installed Python packages are available to any Python command-line environment of a compatible version. To see which Python packages are installed, along with their versions, use pip2 list or pip3.12 list. Similarly, user-installed packages can be viewed using pip2 list --user, pip3.12 list --user or pip3 list --user.

In addition to the many Python packages available in all the versions, users can their own install command-line-accessible packages using an appropriate version of pip install with the --user option. These user-installed packages are installed by default in the user's Home directory, in a directory with a name like ~/.local/lib/pythonN.N/site-packages, where N.N is the Python version.Unlike the R environment, where user-installed packages are automatically visible to the RStudio Server running a compatible R version (see R and RStudio Server R versions), user-installed Python packages

Local/Global package installation conflicts

...

To troubleshoot this possibility, move your local Python installation area out of the way. For example, for Python 3.89:

mv ~/.local/lib/python3.89 ~/.local/lib/python3.89.bak

If this produces a different error indicating that one or more locally installed packages are missing, the user can re-install them then see if the problem is resolved. Check the now-named  ~/.local/lib/pythonN.N.bak/site-packages directory, where N.N is the Python version being used, to see the packages that were locally installed previously. Even if this resolves the immediate issue, the user may later find that they need to re-install other packages that were previously installed locally. 

Finally, if renaming the local Python installation directory does not resolve the issue, it may be an issue with the globally installed packages, so Contact Uscontact us at rctf-support@utexas.edu.

Troubleshooting

...

JupyterHub server issues

In addition to the Local/Global package conflict issue described above, other issues Issues can arise involving JupyterHub server (or less commonly, command-line Python). These browser and disk quota issues are similar to those seen for R, so see Troubleshooting R/RStudio server issues. If all else failsthose suggestions and the ones below fail, submit a help request to our rctf-support@utexas.edu support email.

"Try restarting it from the hub" message

One issue specific to JupyterHub is getting 503: service unavailable. with the message: try restarting it from the hub after logging in with BRCF credentials. Sometime just clicking on the Restart button will work; if not, try logging in again.

JupyterHub Terminal issues

While JupyterHub's Terminal window is a great way to access the Linux command line from your web browser, there are some limitations you should be aware of:

• Some keystrokes and key combinations are not recognized the same way as on the real command line.
  • This is especially true for Ctrl-, Function-, Option- Alt- key combinations.
  • So, for example, editing a file with nano (or vi/vim or emacs) in the JupyterHub Terminal will not work when you try to enter an editor command.
• Be very careful looking at large files in the JupyterHub Terminal, since you may not be able to stop output of long text.
  • Always pipe data from large files to a pager (e.g. more).

Problems arising from these limitations are the main cause of "Zombie" JupyterHub processes, described below.

Zombie processes

If you are unable to login to JupyterHub on one compute server, first try other compute servers on your pod if available.

Being blocked from logging in to JupyterHub on a particular compute server can be due to "zombie" JupyterHub processes that are still in a "running but not running" state. This is particularly common after using JupyterHub's Terminal window, especially if an error was encountered.

To you can find and kill any of your "Zombie" JupyterHub processes like this, after logging in to a specific compute server:

# Find JupyterHub processes associated with <your_account>
ps -ef | grep jupyter

# The 2nd column in the listing, after your user name, is the process ID (PID).
# You can kill a process like this:
kill -9 <PID>