Wolfram Kernel not responding

[ghost]

Hello. My Wolfram Kernel did not respond at all. Jupyter Notebook said the kernel is idle, but when I input "1+1", it didn't output the result.

In the "About" window, it said "Waiting for kernel to be available..." all the time. However, my wolframscript worked properly in ubuntu bash. I'm running JupyterHub with JupyterLab as root on my Ubuntu 18.04 server. Wolfram Engine 12.0.0 I installed the Wolfram Kernel using method 1 configure-jupyter.wls add

(base) root@mryao:~# jupyter kernelspec list
Available kernels:
  python3              /etc/miniconda3/share/jupyter/kernels/python3
  wolframlanguage12    /usr/local/share/jupyter/kernels/wolframlanguage12

[cc-wr]

My guess would be that this is a licensing issue: JupyterHub could be starting jupyter notebook (or jupyter lab) under a user environment that does not permit WolframKernel to discover its license.

When you are able to correctly run the Wolfram Engine (outside of Jupyter), what is the value of $PasswordFile? If $PasswordFile is in a user-specific directory, do you sign into JupyterHub under a different user?

[ghost]

Thanks! My $PasswordFile is /root/.WolframEngine/Licensing/mathpass, which is certainly inaccessible by other users. So how can I change the $PasswordFile to a public directory, or how can I install / activate Wolfram Engine in a non-user-specific way?

[cc-wr]

You could try moving your mathpass file to $BaseDirectory/Licensing/mathpass (e.g., /usr/share/Mathematica/Licensing/mathpass).

[jfultz]

Using $BaseDirectory poses some interesting issues. If @mryaodev is using the free Wolfram Engine, then the mathpass file is periodically updated (I forget exactly how often...maybe once a week or once every few weeks) with a fresh password and a longer expiration date. The updates will still be written to $UserBaseDirectory.

Eventually, each user account would end up getting their own mathpass file, each of which would be independently updating. I think that would actually work, but the more frequent activation checks (if you're routinely rotating through different users) might become more noticeable...particularly as startup delays.

[cc-wr]

Using $BaseDirectory poses some interesting issues. If @mryaodev is using the free Wolfram Engine, then the mathpass file is periodically updated (I forget exactly how often...maybe once a week or once every few weeks) with a fresh password and a longer expiration date. The updates will still be written to $UserBaseDirectory.

I would like to note that Jupyter currently starts WolframLanguageForJupyter through WolframKernel, not wolframscript. According to my understanding, this means that automatic activation would not occur through the use of WolframLanguageForJupyter alone (sans the wolframscript installation method).

A possible solution would be to configure JupyterHub to run wolframscript, reactivating the Wolfram Engine if necessary, and to copy any relevant $UserBaseDirectory licenses to $BaseDirectory — before starting, say, jupyter notebook.

Eventually, each user account would end up getting their own mathpass file, each of which would be independently updating.

Would the authentication details used by wolframscript not be user-specific (by default) also? I do not think having unauthenticated wolframscripts for some set of users would make sense here.

A possible solution would be to update WolframLanguageForJupyter so that it can run under wolframscript, putting the authentication details in a shared location, and using an environment variable to tell wolframscript where the authentication details are.

[jfultz]

@cc-wr, the re-activation is actually done directly by WolframKernel. wolframscript is indeed required to negotiate the initial activation process (effectively proxying the login of a WolframID to the acquisition of a mathpass file), but once the mathpass file is set up, it's maintained by WolframKernel.

I don't think there'll be any noticeable difference with the $UserBaseDirectory trick unless the user is switching back and forth between a sizable number of accounts. But if there is, feel free to ping me. The activation process isn't so easy to comprehend.

If you want to have just the one mathpass file being universally updated, probably the best way is to put it in a location where it can be read and written by all of the relevant users, and then use the command-line arguments -pwfile /full/path/to/mathpass when launching WolframKernel. That will cause WolframKernel to find it in whatever location you specify, and also to prefer it as a write location for new passwords as they're issued.

[ghost]

Many thanks! I've moved mathpass to /usr/share/Mathematica/Licensing/mathpass. But the problem still occurs.

I found this in jupyterhub 's log.

Updating from Wolfram Research server ...
/usr/local/Wolfram/WolframEngine/12.0/SystemFiles/FrontEnd/Binaries/Linux-x86-64/WolframPlayer: error while loading shared libraries: libasound.so.2: cannot open shared object file: No such file or directory

It seems that some files are missing. I also tried on a fresh-new Ubuntu machine, but it still occurs.

[ghost]

After running apt install libasound2, it works! Thank you very much!