Frequently Asked Questions

My Jupyter Notebook Server is killed while my computation was still running. Why?

There are multiple possible reasons:

1. Jupyter Notebook Servers running on https://jupyterhub.ilabt.imec.be are killed automatically after 1 hour of inactivity. “Activity” is defined as doing something in your browser: editing a notebook, using a terminal, etc. Running computations are however not considered as an activity.

   This is intentional: JupyterHub is meant for developping, debugging and analyzing results; but not for doing long running computations. Please create a GPULab Job for running those computations.

   By using GPULab Jobs it is possible to run multiple long running computations in parallel, which make things like parameter sweeps trivial. It also allows GPULab to detect when your computations have finished, so that we can assign the hardware to the next job in the queue.

2. The underlying GPULab job might have run out of memory. You will receive an email when this occurs. Knowing how much memory you need can be tricky, and is typically trial and error. When you’re unsure, you can typically reserve up to 10 or 20 GB without much problem: most slaves have at least this much per GPU. But if you know you don’t need it, please reserve less memory.

3. If you add more than 10GB of data to the docker image, GPULab will kill your notebook and send you an email to inform you about it. If you need a lot of data, use /project_ghent, /project_antwerp or /project_scratch. Note that if you really need to install this much software, you can do that by pre-installing it in a docker image. There is no limit on docker image size, the 10GB limit only affects on how much the image of a container is allowed to “grow”.

I’m getting a 403-error when trying to access my project share or a file/dir in it

In some cases, you might get Invalid response: 403 Forbidden when you try to access /project_ghent, /project_antwerp or /project_scratch, or 403 Permission Denied when your try to create files or directories in /project_ghent, /project_antwerp or /project_scratch.

This occurs when the permissions in your project dir are too restrictive.

This can be triggered by users (including other users in your project) manually changing these permissions, but the typical cause is the virtual wall. The Emulab-software that manages the wall, rewrites the permissions in certain cases (such as starting an experiment on the wall in the project).

This causes problems as the jupyterhub notebook does not run as root, but as a regular user.

You do however have access to sudo, so you can fix things yourself, by opening a terminal in jupyterhub, and executing:

sudo chmod uog+rwx /project_ghent

Or if only a certain subdir is the problem:

sudo chmod -R uog+rwx /project_ghent/mysubdir

How do I run Tensorboard or other web-based UI’s within JupyterHub?

Services like Tensorboard expose their user interface as a website (E.g. Tensorboard launches a webserver on http://localhost:6006).

You can use such tools by accessing them via Jupyter Server Proxy (recommended), or by explicitely exposing a port when launching your Jupyter notebook instance.