You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -152,29 +155,78 @@ clusters, as well as an option to run a local notebook directly on the jupyterhu
152
155
```
153
156
154
157
158
+
## Debugging batchspawner
159
+
160
+
Sometimes it can be hard to debug batchspawner, but it's not really
161
+
once you know how the pieces interact. Check the following places for
162
+
error messages:
163
+
164
+
* Check the JupyterHub logs for errors.
165
+
166
+
* Check the JupyterHub logs for the batch script that got submitted
167
+
and the command used to submit it. Are these correct? (Note that
168
+
there are submission environment variables too, which aren't
169
+
displayed.)
170
+
171
+
* At this point, it's a matter of checking the batch system. Is the
172
+
job ever scheduled? Does it run? Does it succeed? Check the batch
173
+
system status and output of the job. The most comon failure
174
+
patterns are a) job never starting due to bad scheduler options, b)
175
+
job waiting in the queue beyond the `start_timeout`, causing
176
+
JupyterHub to kill the job.
177
+
178
+
* At this point the job starts. Does it fail immediately, or before
179
+
Jupyter starts? Check the scheduler output files (stdout/stderr of
180
+
the job), wherever it is stored. To debug the job script, you can
181
+
add debugging into the batch script, such as an `env` or `set
182
+
-x`.
183
+
184
+
* At this point Jupyter itself starts - check its error messages. Is
185
+
it starting with the right options? Can it communicate with the
186
+
hub? At this point there usually isn't anything
187
+
batchspawner-specific, with the one exception below. The error log
188
+
would be in the batch script output (same file as above). There may
189
+
also be clues in the JupyterHub logfile.
190
+
191
+
Common problems:
192
+
193
+
* Did you `import batchspawner` in the `jupyterhub_config.py` file?
194
+
This is needed in order to activate the batchspawer API in
195
+
JupyterHub.
196
+
197
+
198
+
155
199
## Changelog
156
200
157
-
### dev (requires minimum JupyterHub 0.7.2 and Python 3.4)
201
+
### dev (requires minimum JupyterHub 0.9 and Python 3.5)
158
202
159
203
Added (user)
160
204
161
205
* Add Jinja2 templating as an option for all scripts and commands. If '{{' or `{%` is used anywhere in the string, it is used as a jinja2 template.
162
206
* Add new option exec_prefix, which defaults to `sudo -E -u {username}`. This replaces explicit `sudo` in every batch command - changes in local commands may be needed.
163
207
* New option: `req_keepvars_extra`, which allows keeping extra variables in addition to what is defined by JupyterHub itself (addition of variables to keep instead of replacement). #99
164
208
* Add `req_prologue` and `req_epilogue` options to scripts which are inserted before/after the main jupyterhub-singleuser command, which allow for generic setup/cleanup without overriding the entire script. #96
165
-
* SlurmSpawner: add the `req_reservation` option. #
209
+
* SlurmSpawner: add the `req_reservation` option. #91
210
+
* Add basic support for JupyterHub progress updates, but this is not used much yet. #86
166
211
167
212
Added (developer)
168
213
169
214
* Add many more tests.
170
215
* Add a new page `SPAWNERS.md` which information on specific spawners. Begin trying to collect a list of spawner-specific contacts. #97
216
+
* Rename `current_ip` and `current_port` commands to `ip` and `port`. No user impact. #139
217
+
* Update to Python 3.5 `async` / `await` syntax to support JupyterHub progress updates. #90
171
218
172
219
Changed
173
220
174
-
* Update minimum requirements to JupyterHub 0.8.1 and Python 3.4.
221
+
* PR #58 and #141 changes logic of port selection, so that it is selected *after* the singleuser server starts. This means that the port number has to be conveyed back to JupyterHub. This requires the following changes:
- Add a new option `batchspawner_singleuser_cmd` which is used as a wrapper in the single-user servers, which conveys the remote port back to JupyterHub. This is now an integral part of the spawn process.
224
+
- If you have installed with `pip install -e`, you will have to re-install so that the new script `batchspawner-singleuser` is added to `$PATH`.
225
+
* Update minimum requirements to JupyterHub 0.9 and Python 3.5. #143
175
226
* Update Slurm batch script. Now, the single-user notebook is run in a job step, with a wrapper of `srun`. This may need to be removed using `req_srun=''` if you don't want environment variables limited.
176
227
* Pass the environment dictionary to the queue and cancel commands as well. This is mostly user environment, but may be useful to these commands as well in some cases. #108, #111 If these environment variables were used for authentication as an admin, be aware that there are pre-existing security issues because they may be passed to the user via the batch submit command, see #82.
177
228
229
+
178
230
Fixed
179
231
180
232
* Improve debugging on failed submission by raising errors including error messages from the commands. #106
0 commit comments