jupyter_server icon indicating copy to clipboard operation
jupyter_server copied to clipboard

using systemd activated sockets

Open phr34k opened this issue 3 years ago • 3 comments

I used to have an module that would patch the underlying http (tornado) server, to patch in support for systemd activated sockets (SYSTEMD_SOCKET_FD ). To allow for systemd to accept traffic while there's no running instance (yet) and spawn a handling jupyter process on-demand, and terminate it after an idle period, preserving system resources.

https://gist.github.com/phr34k/adc6aaa6df212ea6791a0732b807a67f

This worked great, but hadn't had the time to keep the stack up to date and only recently discovered my module is no longer compatible with latest iteration of the code. I tried to look into the changes to figure out but honestly I sort-off lost oversight what happened to all the internals.

What I would like to know with the current code if there's an better/improved way of accomplishing this throughout some of the new extensions or if I could still patch it in similar way and how if so. From what i can tell, is that these LabApps now use something called a shim and I think that's where it goes wrong.

I got recommendation to file this question over here so I'm hoping somebody with a better understanding of the internals could give me some pointers.

phr34k avatar Mar 25 '22 18:03 phr34k

Thank you for opening your first issue in this project! Engagement like this is essential for open source projects! :hugs:
If you haven't done so already, check out Jupyter's Code of Conduct. Also, please try to follow the issue template as it helps other other community members to contribute more effectively. welcome You can meet the other Jovyans by joining our Discourse forum. There is also an intro thread there where you can stop by and say Hi! :wave:
Welcome to the Jupyter community! :tada:

welcome[bot] avatar Mar 25 '22 18:03 welcome[bot]

The quick change is likely that a newer jupyter lab process will actually have a app.serverapp instead of an app.notebookapp.

At present, it looks like one could subclass the server's init_httpserver to avoid having to monkeypatch the hot object.

however, an httpserver_class could be an interesting configurable as well: this would allow you to package your small server, e.g systemdnado and ship a single file in data_files to configure it.

bollwyvl avatar Mar 26 '22 13:03 bollwyvl

Jupyter Server already supports listening on two types of sockets (tcp and bsd) based on config. It sounds like this makes sense as a third option in the same place.

minrk avatar Mar 28 '22 13:03 minrk