On Thursday, June 8, 2017 at 7:24:57 AM UTC-7, takowl wrote: > > On 8 June 2017 at 04:04, Brendan Barnwell <[email protected] <javascript:> > > wrote: > >> What I would like is the ability to start a notebook server that would >> automatically shut down once the associated browser is closed. Looking at >> old messages on the list, I get the impression this isn't possible. Is >> that correct? >> > > With a special-purpose browser that knows about the notebook server, yes - > the browser can either use SIGTERM when it closes to shut down the notebook > server, or when notebook 5.1 is released, it will be able to POST to > /api/shutdown > > https://github.com/jupyter/notebook/pull/2507 > <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fjupyter%2Fnotebook%2Fpull%2F2507&sa=D&sntz=1&usg=AFQjCNGFVKoHvkhWnrrpzrSfPcnCg8Y3IA> >
Oh, that sounds like it might be perfect. Ideally I'd like to be able to do everything by communicating with the server rather than launching processes. > > It seems like it would be possible to implement this by having JavaScript >> in the notebook page send keepalive messages back to the server. These >> would serve as a sort of "dead man's switch" --- as long as the page >> remained open, the server would remain alive, but when the browser (or tab >> in a multi-tab browser) was closed, the cessation of keepalive messages >> would tell the server to shut itself down. Is this feasible? >> > > Feasible, and we already monitor connectivity to the kernel, but I don't > think we'd ever do that by default - we don't want to kill the notebook > server if your connection to it goes down. Even locally, 'keep alive' > messages can be tricky to get right when computers go into standby. > > Plus, of course, many people expect their notebook server to stay running > without an open browser tab on it. > Yeah, I wasn't imagining that that would be the default, but that there would be a command-line option --dead-man-switch or something. While I agree it wouldn't handle many cases, the situation I'm imagining is one where you're just using the notebook as if it were a regular program (not a long-running server that you connect to again and again). > > >> Failing that, I've also been looking for documentation on how to >> programmatically start the notebook server. That is, supposing I'm running >> some Python code, how can I, from within that code, do the equivalent of >> "jupyter notebook --no-browser", and get the login token returned as a >> string so that I can redirect my wrapper to the appropriate URL? Right now >> the only way I can see is to actually run jupyter using subprocess and >> parse the output, but that seems rather awkward. Is there a part of the >> notebook that I can import as a module and do something like "server = >> notebook.start_server()" and then "token = server.token"? >> > > Not quite as neat as that, but you can get info on the current user's > running notebook servers by calling: > > notebook.notebookapp.list_running_servers() > > You should be able to find the one you've just started as a subprocess by > checking the PIDs. That's easier than parsing info from stdout/stderr. > > Hmmmm, okay, that looks promising. One thing I'm wondering is whether there's a way to get any of this information by communicating with the notebook server itself. It would be nice if I could write my wrapper so it really acted as a browser from Jupyter's perspective, with the notebook starting it rather than the other way around. The reason I'd feel more comfortable with this is that it would make the wrapper more independent of Jupyter, and thus (I hope) more robust to a situation where the wrapper is, for instance, running on a different version of Python than the notebook itself. For instance, I'd like it if I could have my wrapper installed in just one Python environment (an Anaconda environment, say), but be able to run notebooks from arbitrary Python versions. If I call list_running_servers from one Python process, is it guaranteed to show me all servers, even if they're running on different versions of Python? Also, if the wrapper is the entry point and runs the notebook as a subprocess, then in my wrapper code I'd have to handle all the business of letting the user specify which Python they want the notebook server to run in. But if jupyter is the entry point, then it already provides a way to specify the browser. So if I can handle everything by communication with the server then I wouldn't have to worry about starting a separate Jupyter instance (e.g., to list servers) inside the wrapper. In theory, Jupyter wouldn't even need to be installed in the Python that's running the wrapper. In any case, thanks for your helpful comments. They've given me some directions to explore. -- You received this message because you are subscribed to the Google Groups "Project Jupyter" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/0b0f63cf-365f-484d-a1bf-a4373bcec246%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
