Skip to content
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

Pass launch_instance args on correctly. #4039

Merged
merged 2 commits into from
Sep 13, 2022

Conversation

hjoliver
Copy link
Contributor

Greetings JupyterHub experts. Thanks for your excellent software!

Tentative bug fix:

I think the hub launch_instance class method should be passing its args on to launch_instance_async(?), but currently it is passing them to loop.run_sync which is expecting a timeout value there.

@welcome
Copy link

welcome bot commented Sep 12, 2022

Thanks for submitting your first pull request! You are awesome! 🤗

If you haven't done so already, check out Jupyter's Code of Conduct. Also, please make sure you followed the pull request template, as this will help us review your contribution more quickly.
welcome
You can meet the other Jovyans by joining our Discourse forum. There is also a intro thread there where you can stop by and say Hi! 👋

Welcome to the Jupyter community! 🎉

@hjoliver
Copy link
Contributor Author

(Contrary to the automated advice above, the Pull Request Template appears to be empty).

@hjoliver
Copy link
Contributor Author

Note, older versions (JupyterHub 2.3.1) do pass argv on to launch_instance_async as I've described:

# JupyterHub 2.3.1 app.py
3300     @classmethod                    
3301     def launch_instance(cls, argv=None):                   
3302         self = cls.instance()               
3303         self._init_asyncio_patch()             
3304         loop = IOLoop.current()     
3305         task = asyncio.ensure_future(self.launch_instance_async(argv))  # <------- HERE
...

@minrk
Copy link
Member

minrk commented Sep 13, 2022

Thanks! Added a test to make sure we don't reintroduce similar bugs.

Will do a 3.0.1 pretty soon after some more 3.0 feedback.

@minrk minrk merged commit 29ffb23 into jupyterhub:main Sep 13, 2022
@welcome
Copy link

welcome bot commented Sep 13, 2022

Congrats on your first merged pull request in this project! 🎉
congrats
Thank you for contributing, we are very proud of you! ❤️

@timeu
Copy link

timeu commented Oct 21, 2022

We upgraded JupyterHub to 3.0.0 but the container with jupyter-singleuser 3.0.0 sessions spawened by the batchspwaner fail to callback to the hub and the session is stuck in pending. It works fine with jupyter-singleuser 2.3.1 sessions tough.
Could this be related to this issue ?
In the logs I noticed following line at the start:

/srv/conda/envs/notebook/lib/python3.9/subprocess.py:941: RuntimeWarning: line buffering (buffering=1) isn't supported in binary mode, the default buffer size will be used
  self.stdout = io.open(c2pread, 'rb', bufsize)
/srv/conda/envs/notebook/lib/python3.9/site-packages/batchspawner/singleuser.py:17: RuntimeWarning: coroutine 'HubAuth._api_request' was never awaited
  hub_auth._api_request(
RuntimeWarning: Enable tracemalloc to get the object allocation traceback

@minrk minrk added the bug label Nov 24, 2022
@elia427
Copy link

elia427 commented May 24, 2023

@timeu I am experiencing a similar issue. Did you manage to fix it?

@timeu
Copy link

timeu commented May 24, 2023

pinning jupyter-singleuser to < 3.0.0 or upgrading to the latest jupyterhub (>=4.0.0) fixed our issue

@elia427
Copy link

elia427 commented May 24, 2023

@timeu Thanks for the prompt reply. That doesn't seem working for me. I am running jupyterhub 4.0.0 and jupyterhub-singleuser 4.0.0.

@elia427
Copy link

elia427 commented May 25, 2023

#251 fixed my issue. 🥇

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants