1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
|
# Next Steps
Whenever we start a notebook let's generate an id (put the id in a db or in memory start) and then accept the id as
part of the route to get to the notebook.
The server has to look that id up and route the user to that particular jupyter notebook instance.
Currently, users are directed to a jupyter notebook instance via parsing the output of `list_running_servers`:
=> https://git.genenetwork.org/jgart/binderlite/src/branch/master/app.py#L37 list_running_servers in binderlite src
This has its issues because we cannot uniquely identify the last launched notebook.
## Optimizations
### Shutdown notebook and save to memory
If we are shutting down the notebook to save memory then we want
to remember it's location in order to return to it.
The jupyter notebook API has a function for listing currently running notebooks (mentioned above):
```
def list_running_servers(runtime_dir=None):
"""Iterate over the server info files of running notebook servers.
Given a runtime directory, find nbserver-* files in the security directory,
and yield dicts of their information, each one pertaining to
a currently running notebook server instance.
"""
```
There is also a function for getting a timestamp of the last time the notebook server did something:
```
def last_activity(self):
"""Get a UTC timestamp for when the server last did something.
Includes: API activity, kernel activity, kernel shutdown, and terminal
activity.
"""
```
I need to decide on a way to uniquely identify the last built jupyter notebook.
### Shutdown kernels gracefully
* shutdown jupyter gracefully
Find a way to shutdown jupyter kernels gracefully. Jupyter kernels are currently shutdown by sending a kill signal
(SIGINT, Ctrl+c) via the terminal.
This currently produces the following error:
```
Exception in thread Thread-1:
Traceback (most recent call last):
File "/gnu/store/sd2ic7bpv8fx3imy1j8xcjclx71sv6q0-python-3.8.2/lib/python3.8/threading.py", line 932, in _bootstrap_inner
self.run()
File "/gnu/store/sd2ic7bpv8fx3imy1j8xcjclx71sv6q0-python-3.8.2/lib/python3.8/threading.py", line 870, in run
self._target(*self._args, **self._kwargs)
File "/gnu/store/w9bgs701xg1gbhxb6a4fsrjkj10c4sxc-python-notebook-6.3.0/lib/python3.8/site-packages/notebook/notebookapp.py", line 1961, in _confirm_exit
line = sys.stdin.readline()
OSError: [Errno 5] Input/output error
```
## guix-kernel runs by default in a container
guix-kernel (AKA guix-jupyter) runs by default in a container.
See here:
=> https://gitlab.inria.fr/guix-hpc/guix-kernel/-/blob/master/guix/jupyter/kernel.scm#L181 eval/container*
The reason I bring this up is because I currently run binderlite without the `--container` flag.
If I try to run it with the `--container` flag then I run into permission issues due to running a container
inside another container.
## Question(s)
###
What is the idiomatic way in nginx to forward everything beyond some prefix.
Currently using the $rest arg but that might not be a good way to do it:
=> https://git.genenetwork.org/jgart/binderlite/src/branch/master/nginx.conf#L36
###
Do we want to avoid hard coding guix-kernel to run inside a container and instead be able to explicitly
specify a container environment from the binderlite app or should this be left to guix-kernel?
See above section on guix-kernel running by default in a container.
Suggestion: we will create our own derived kernels and dependencies.
###
I currently cannot kill running jupyter instances on penguin2:
```
kill-jupyter
kill: (1251): Operation not permitted
kill: (34495): No such process
kill: (52689): Operation not permitted
kill: (52720): Operation not permitted
kill: (52956): Operation not permitted
Killed
```
=> https://git.genenetwork.org/jgart/binderlite/src/branch/master/bin/kill-jupyter kill-jupyter
How should I get around this?
Suggestion: try killing a container rather then the jupyter process. Use the pid of the container.
|
