# Troubleshooting¶

When troubleshooting, you may see unexpected behaviors or receive an error message. This section provide links for identifying the cause of the problem and how to resolve it.

Behavior

• JupyterHub proxy fails to start

• sudospawner fails to run

• What is the default behavior when none of the lists (admin, allowed, allowed groups) are set?

• JupyterHub Docker container not accessible at localhost

Errors

• 500 error after spawning my single-user server

How do I…?

• Use a chained SSL certificate

• Install JupyterHub without a network connection

• I want access to the whole filesystem, but still default users to their home directory

• How do I increase the number of pySpark executors on YARN?

• How do I use JupyterLab’s prerelease version with JupyterHub?

• How do I set up JupyterHub for a workshop (when users are not known ahead of time)?

• How do I set up rotating daily logs?

• Toree integration with HDFS rack awareness script

• Where do I find Docker images and Dockerfiles related to JupyterHub?

Troubleshooting commands

## Behavior¶

### JupyterHub proxy fails to start¶

If you have tried to start the JupyterHub proxy and it fails to start:

• check if the JupyterHub IP configuration setting is c.JupyterHub.ip = '*'; if it is, try c.JupyterHub.ip = ''

• Try starting with jupyterhub --ip=0.0.0.0

Note: If this occurs on Ubuntu/Debian, check that the you are using a recent version of node. Some versions of Ubuntu/Debian come with a version of node that is very old, and it is necessary to update node.

### sudospawner fails to run¶

If the sudospawner script is not found in the path, sudospawner will not run. To avoid this, specify sudospawner’s absolute path. For example, start jupyterhub with:

jupyterhub --SudoSpawner.sudospawner_path='/absolute/path/to/sudospawner'


c.SudoSpawner.sudospawner_path = '/absolute/path/to/sudospawner'


to the config file, jupyterhub_config.py.

### What is the default behavior when none of the lists (admin, allowed, allowed groups) are set?¶

When nothing is given for these lists, there will be no admins, and all users who can authenticate on the system (i.e. all the unix users on the server with a password) will be allowed to start a server. The allowed username set lets you limit this to a particular set of users, and admin_users lets you specify who among them may use the admin interface (not necessary, unless you need to do things like inspect other users’ servers, or modify the user list at runtime).

### JupyterHub Docker container not accessible at localhost¶

Even though the command to start your Docker container exposes port 8000 (docker run -p 8000:8000 -d --name jupyterhub jupyterhub/jupyterhub jupyterhub), it is possible that the IP address itself is not accessible/visible. As a result when you try http://localhost:8000 in your browser, you are unable to connect even though the container is running properly. One workaround is to explicitly tell Jupyterhub to start at 0.0.0.0 which is visible to everyone. Try this command: docker run -p 8000:8000 -d --name jupyterhub jupyterhub/jupyterhub jupyterhub --ip 0.0.0.0 --port 8000

### How can I kill ports from JupyterHub managed services that have been orphaned?¶

I started JupyterHub + nbgrader on the same host without containers. When I try to restart JupyterHub + nbgrader with this configuration, errors appear that the service accounts cannot start because the ports are being used.

How can I kill the processes that are using these ports?

Run the following command: