Exception shutting down kernel from notebook dashboard (0.13.1)

[drevicko]

I got this exception in the console, seemingly when I was shutting down a kernel from the notebook dashboard (to be honest, I'm not 100% sure of that..).

A couple of possible red herrings:

• I'd been putting the computer under a bit of stress: a notebook (not sure which kernel) had been loading rather large amounts of data, and a few times pushed the computer well into swapping memory (ie: it ran like a dog). I had re-started it several times, and I believe I'd killed it (SIGTERM I think) at least once.
• I had some ssh pipes open (for a mongodb replica set) which the memory hogging notebook was using. One of the replicas (not the PRIMARY - that's local) had been restarted, which would have broken the pipe. I say this because another python program polling the twitter api (lots of https connections) ran into trouble - I believe it's trouble was a httplib problem with ssl handshake timeouts, but a stuck ssh pipe may have contributed??

Here's an except from the console (with some added bolding..):

[NotebookApp] Kernel started: 86ab6603-0ccb-425e-b0fd-311c8de7469d
[NotebookApp] Connecting to: tcp://127.0.0.1:52176
[IPKernelApp] To connect another client to this kernel, use:
[IPKernelApp] --existing kernel- 86ab6603-0ccb-425e-b0fd-311c8de7469d .json
[NotebookApp] Connecting to: tcp://127.0.0.1:36924
[NotebookApp] Connecting to: tcp://127.0.0.1:55392
[NotebookApp] Kernel restarted: a8152817-4926-4031-8bd5-19f3e40c0e44
[NotebookApp] Connecting to: tcp://127.0.0.1:53086
[NotebookApp] Connecting to: tcp://127.0.0.1:49990
[NotebookApp] Connecting to: tcp://127.0.0.1:54846
[IPKernelApp] To connect another client to this kernel, use:
[IPKernelApp] --existing kernel-a8152817-4926-4031-8bd5-19f3e40c0e44.json
[NotebookApp] Kernel shutdown: a8152817-4926-4031-8bd5-19f3e40c0e44
[NotebookApp] Using existing kernel: 86ab6603-0ccb-425e-b0fd-311c8de7469d
[NotebookApp] Connecting to: tcp://127.0.0.1:52176
[NotebookApp] Connecting to: tcp://127.0.0.1:36924
[NotebookApp] Connecting to: tcp://127.0.0.1:55392
Unhandled exception in thread started by <bound method ParentPollerUnix.__bootstrap of <ParentPollerUnix(Thread-1, stopped daemon 140106875700992)>>
Error in sys.excepthook:
Traceback (most recent call last):
File "/usr/local/lib/python2.7/dist-packages/IPython/core/ultratb.py", line 1028, in call
self.handler((etype, evalue, etb))
File "/usr/local/lib/python2.7/dist-packages/IPython/core/ultratb.py", line 1017, in handler
ostream.write(self.text(etype, evalue, etb))
File "/usr/local/lib/python2.7/dist-packages/IPython/core/ultratb.py", line 412, in text
tb_offset, context)
File "/usr/local/lib/python2.7/dist-packages/IPython/core/ultratb.py", line 1078, in structured_traceback
return VerboseTB.structured_traceback(
AttributeError: 'NoneType' object has no attribute 'structured_traceback'

Original exception was:
Traceback (most recent call last):
File "/usr/lib/python2.7/threading.py", line 524, in __bootstrap
self.__bootstrap_inner()
File "/usr/lib/python2.7/threading.py", line 564, in __bootstrap_inner
(self.name, _format_exc()))
File "/usr/lib/python2.7/traceback.py", line 240, in format_exc
etype, value, tb = sys.exc_info()
AttributeError: 'NoneType' object has no attribute 'exc_info'
[NotebookApp] Kernel shutdown: 86ab6603-0ccb-425e-b0fd-311c8de7469d

[minrk]

There doesn't appear to be any great issue here - you had threads open, and they tried to do things after some of the stdlib had started to be garbage collected. This is a thing that happens with threads sometimes.

[drevicko]

ok, that makes sense. Perhaps I'd killed a kernel that was getting unwieldy, and it had to wait for a db call to return, by which time stdlib had been dumped? I'll have to admit I've seen similar before, but not thought it important enough to report..