-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New Instance allocated in server_tracking DB for some users #15
Comments
Hi Andrew Three years ago when I used GitHub module for authentication, I faced the problem of having two instances registered for the same user . It turn out that the user have two GitHub accounts. Therefore, when the user logged in with one account, the hub created an instance and registered the instance id with the username in the database. Later when the same user logged in but with the second account, jupyterhub created different instance for the same user and registered the instance id and the second user name in the database. You might have the same issue, but if we leave the guessing aside, for me to check what is happening I need to see your jupyterhub logs (located in /var/log/jupyterhub ) and the config file (remove the credentials ). I also need to see your GitHub authentication module and the list of usernames that get multiple instances. |
Thanks Faras, I really appreciate the followup. |
Send a compressed version to my email [email protected]. |
We have around 100 students logging in to JupyterHub, and some have found that if they log out, and then log back in they are given a new instance. This is very disconcerting, as it appears as though they have lost all of there previous work!
Looking at AWS, it appears that the old instance is still there and running in AWS, but the student's GitHub account has been associated with a new instance in the server_tracking DB.
Any suggestions on why this has occurred and how to stop it recurring?
Could this be load problem? What causes a new instance to be allocated to a user?
Also, is there a way of tracking down these orphaned instances? Perhaps by matching IP address, or looking for instance IDs that are not in server_tracking?
Thanks. I'd appreciate your assistance.
The text was updated successfully, but these errors were encountered: