Kernal status is stuck to unknown for python
and code not showing output is stuck to [*].
I tried restarting kernel, but doesn’t work.
So that isn’t typical Python. You may know that and be using “python” for shorthand in what I am quoting. However, it could be a big deal because it determines your options and how you troubleshoot this.
What you are showing is using Pyodide running in JupyterLite, which runs a more limited version of Python in a kernel. The important distinction is that this Pyodide-based kernel is running inside your browser using WebAssembly (WASM). Because there’s layers here and it involves computation running inside a virtual machine in your browser there’s lots of points it can go wrong and glitch up. It just looks like you encountered a glitch.
There’s some options in how to proceed. And it sort of depends on your long term goal here. (You may want to read more about the limitations with JupyterLite here. Above that section, I describe how to use typical Python-based kernels running on remote machines via MyBinder. It will run more reliably and because it is an actual typical Python kernel, it will run more like you see things described for Python. By contrast, Pyodide has some rough edges still to it that makes using it different or more limited, aside from being prone to glitching.)
The easiest way to troubleshoot this right now, without considering different sources of running Jupyter/Python, is to first try opening a new notebook in the same session
and patiently see if it gets to ready status with indicator in the upper right an open circle. Or open the site you are trying to use in the same browser in ‘Incognito’ mode or ‘Private browsing’, depending on your browser. Be patient and let the kernel start up before you attempt to run any code. Let the status indicator in the upper right side become ‘open’/ready. And then try running your code.
Alternatively, open a new browser, if you have another installed. For example, if you are using Chrome, switch to try using Firefox. Again, be patient when starting up the kernel to not run code too soon before the status says ready.
Note for both of these latter approaches, you won’t see your old work that you already did because they are both different ways to get new, fresh JupyterLite sessions. You should though still have where you were working before in your original browser and be able to see your old notebooks you already ran. Because they are actually inside a virtual system in your browser, you’ll need to download them to your actual local machine’s system interface and store the .ipynb files on your hard drive like you’d store any local file. (Make a habit to do this often.) You should then be able to drag and drop the previous notebooks into the new sessions, too. Because your browser can go kablooie at any time, I try to urge users to consider JupyterLite like using a remote machine and download the .ipynb files regularly to your local machine for use later. Later meaning days or months or years from now when you have a new browser on a new machine, etc…
You can also simply take your JupyterLite content to another JupyterLite source, if you know of one. Sometimes that works instead of switching modes or browsers.
I should have added that the glitch can be temporary, or it can be associated with that page and no matter what, it won’t every go back to a ready status without drastic measures best avoided considering you may be using your browser cache to now store your notebooks. (That is a bad idea, see advice above to ‘download’ anything useful to your local file system.) Usually the glitch is temporary, and opening a new notebook file or the tricks of using different modes or browser, I mentioned above can get you past even the worse ones for today. Sometimes it may start up and run a few days from now, just fine.
2 Likes