Dead Kernels in IJulia on Windows

Try as I might, there is a single computer that I can’t seem to get IJulia working on. It’s likely a Windows issue, so I’m hoping someone here could spot what it is.

https://github.com/JuliaLang/IJulia.jl/issues/546

Lots of details in the issue, and I’m ready to post any more diagnostics to get this going.

A tip for the future is to make sure that you file the issues with the package that is the source of the bug. In this case, it looks like the problem occurs in WinRPM, which is not even called directly by IJulia (it’s invoked by one of the dependencies). Also, be wary of posting the same question in multiple forums.

1 Like

I started with an error from IJulia. I got that installation error from WinRPM 4 days after the original post. You can see in the original Pkg.build("IJulia") output that did not happen. The moment I got that error message I filed an issue at that package.

See the timestamps on when the issue was updated and when the WinRPM. Thus I did this, at least according to the knowledge I had at each point.

It’s not clear to me why it would matter. The error causes WinRPM to fail downloading the 32-bit version of ZMQ and then download an install the 64-bit version. I am using a 64-bit OS with a 64-bit Julia installation. It’s definitely not clear to me that getting that problem fixed is anything but a sideshow, but I posted the update because it’s a new warning message I am seeing so maybe that could spot something.

I was weary. I didn’t do it for four days because I thought it was just an IJulia issue. But now that it has the possibility of being some larger Windows ecosystem tooling issue (and you seem to agree, given the idea that it could possibly be do to WinRPM or ZMQ). So, by your own admission, this issue seems to span multiple packages, making it not really fit in a single Github issue focused just on IJulia. So I am transferring this over to the discussion forum I think suits this multiple package installation issue best: Discourse. As part of that transfer, I mentioned and linked to the issue where it all started (which also has all of the printouts).

Honestly, I thought I pretty much followed spot on what the “correct” policy for bug reporting would be. I posted printouts every time I rebuilt and got something different out, used other computers to try to reproduce (at first succeeded, and then somehow after restarting failed) the bug (and documented this), set it into the appropriate debugging mode and posted the printout, identified potentially related problems and filed issues for those, and then days after when it started to seem like the issue was in the wrong place because of the new information, I moved the issue to what seemed like a place that would be a better fit. Please feel free to ping me in a separate discussion on the proper policy for bug reports if you want to discuss this further, because I honestly do not know why I would receive backlash for going through these steps when trying to identify and fix the installation issue.

Sorry, I didn’t intend my post as a “backlash”; I’m just trying to provide some helpful advice about why you might be getting limited help.

A big part of debugging is trying to narrow down a problem to a minimal amount of code that reproducibly exhibits a single error, and then reporting the error to the people responsible for that code (if you can’t figure it out yourself). Here, it’s hard for me to even figure out what problem you are reporting in the IJulia issue linked above because so many issues are mixed together:

  • You started with an ImportError: No module named site when you launch jupyter notebook on the command line, which doesn’t involve Julia at all and could be a problem in your Python/Conda install.
  • You then got Assertion failed: Socket operation on non-socket error from jupyter notebook that may indicate a ZMQ library mismatch problem (e.g. https://github.com/spyder-ide/spyder/issues/3106).
  • You then have an WARNING: Unknown download failure, error code: 2148270086 error that seems to originate in WinRPM.

At first glance, it looks like none of these problems involve a single line of IJulia code.

The MWE I’ve been working with is:

  1. Starting with a wiped package repository, Pkg.add("IJulia")
  2. using IJulia
  3. notebook()
  4. Open a new notebook with a Julia kernel
  5. Watch the kernel repeatedly die and ask to restart.

Please let me know if there’s a simpler test than that. Otherwise this is the simplest way I know to reproduce the the issue that I am having, which is that the kernels keep dying and restarting in IJulia.

That wasn’t mentioned before. I thought it was some IJulia problem. But since it’s a ZMQ problem, I ran Pkg.test("ZMQ") and see that there is an issue there:

Maybe that will solve it.

Googling the error message (“Assertion failed: Socket operation on non-socket error”) is always a good thing to try — in this case, it turns up the fact that it is a libzmq assertion.

1 Like

Yeah, I missed that in the debugging output. That was my bad.