When I start the Mathematica 9 Front End, and check the list of running processes, I see two separate MathKernel processes. If I only start the kernel, without a front end, then there's only one process running. I'm on OS X. Do others also see two processes? What about other operating systems? What is the purpose of having two MathKernel processes running?

ps ux | grep Math gives me this:

szhorvat  1077   7.0  0.7  1136220 110948   ??  S     7:01PM   0:13.46 /Applications/Mathematica 9.app/Contents/MacOS/Mathematica -psn_0_712878
szhorvat  1080   0.5  0.3  2637284  46084   ??  S     7:01PM   0:00.81 /Applications/Mathematica 9.app/Contents/MacOS/MathKernel -nopaclet -noinit -pwfile /Applications/Mathematica 9.app/Configuration/Licensing/playerpass -mathlink -linkmode connect -linkprotocol SharedMemory -linkname dvm_shm
szhorvat  1083   0.1  0.4  2634236  67284   ??  S     7:01PM   0:01.30 /Applications/Mathematica 9.app/Contents/MacOS/MathKernel -mathlink -linkmode connect -linkprotocol SharedMemory -linkname gny_shm
szhorvat  1103   0.0  0.0  2432768    620 s001  R+    7:02PM   0:00.00 grep Math
  • 3
    $\begingroup$ I believe the front end started using its own kernel as of version 9. I suspect this might have something to do with running the predictive interface. $\endgroup$
    – Andy Ross
    Commented Mar 22, 2013 at 23:06
  • $\begingroup$ I think one is for the FrontEnd and another is for the user. $\endgroup$ Commented Mar 22, 2013 at 23:12
  • 2
    $\begingroup$ Funny is, that the second kernel uses playerpass as password file but if you move the file (or change its contents) it doesn't seem to bother Mathematica. I wished we would have this behavior for the main kernel. $\endgroup$
    – halirutan
    Commented Mar 23, 2013 at 0:01
  • $\begingroup$ Its also present on Windows. $\endgroup$
    – s0rce
    Commented Mar 23, 2013 at 0:14
  • 4
    $\begingroup$ Accessing the kernel is easy. Just set the Evaluator option to "System". E.g., Dynamic[$PasswordFile, Evaluator -> "System"]. That's exactly how we do it for our code. It doesn't require privileged access or anything. But completion doesn't run through the System kernel. See my answer for an explanation. And, if you destabilize the System kernel...well, that's on you. $\endgroup$
    – John Fultz
    Commented Aug 7, 2013 at 17:20

1 Answer 1


As people have figured out in the comments, this was a quite deliberate decision on our part. One which I can take a significant amount of credit/responsibility/blame for.

First a little bit about the extra kernel. The kernel is enabled using a password which causes it to run in Wolfram Player mode. It runs using the same binary as the regular kernel, but it runs in a limited mode which prevents it from being fully functional (for example, there are serious limitations on writing to disk). Most importantly, it does not use up one of your kernel license slots.

Beginning in version 6, the front end has been increasingly leaning on kernel programming to do a lot of stuff that had, previously, been relegated to C++ code in the front end binary (a testament to the increasing power of the underlying product). Many dialog boxes are driven by kernel programming. The help viewer has lots of kernel functionality behind it. Even some menu commands invoke the kernel to work properly. This became something of a problem for people who like to modify their default kernels; especially if the default kernel happens to be a remote kernel, where the transport mechanism could really slow down FE dynamic interfaces. So, I believe in v7, we started locking down the Local kernel as a "special" kernel which would only allow limited changes and would always be running. But I was never really satisfied with this solution. It seemed really hacky, and potentially penalizes users by soaking up a kernel license they might not wish to run.

In v9, we came up with the idea of a "service kernel". This kernel exists only to service the front end. True, it runs as a separate process, but that doesn't use as much real extra resources as you might think. Caching and memory-mapped files leads to a lot of reuse or efficiencies for running multiple copies of the same binary. And the FE doesn't push its kernel very hard, so it's not going to be allocating a lot of memory for FE programs. But the important point is that the FE kernel is available when the user kernel may not be. Maybe it's not available because the user didn't want to launch it. Or maybe because the user's busy doing real computational work, but doesn't want that work making it difficult to do something like running the Find dialog or copying some formula to MS Word (to pick two real examples that rely on the kernel).

In the future, I would expect more computation to shift to the service kernel. I was disappointed, for example, that we weren't able to run all help viewer operations in the kernel. But the trajectory moves us back to a place where the Local kernel, or whatever a user wants his/her kernel to be, is really now their own and not being borrowed to run FE operations. Of course some FE operations must always run in the user's kernel because they rely on probing kernel state -- most notably syntax coloring and auto-completion. But we'll offload as much of the other stuff as we can to the service kernel.

  • 1
    $\begingroup$ Perhaps converting between InputForm/StandardForm/TraditionalForm could also be shifted to the service kernel, so these operations can work while a computation is ongoing. Just an idea for making the FE more convenient. $\endgroup$
    – Szabolcs
    Commented Sep 16, 2013 at 19:21
  • $\begingroup$ Is there a way to tell whether code is running on this service kernel? (I have a paclet set to autoload on startup, and it appears to be causing issues in the service kernel, so I'd like to prevent it from doing anything there) $\endgroup$
    – Lukas Lang
    Commented Oct 22, 2021 at 10:31
  • $\begingroup$ @LukasLang , the service kernel isn't supposed to be running any user-level initialization at all (so that it can always be in a known state for built-in FE operations). So it shouldn't be running any startup code from your paclet. If the paclet produces user interfaces, they would only use the kernel if they have the FE option Evaluator->"System" set. Of course there might be some bug somewhere, but those are the defined behaviors. $\endgroup$
    – John Fultz
    Commented Oct 22, 2021 at 18:24
  • $\begingroup$ @JohnFultz Thanks - I should have mention that the paclet has Loading->"Startup" set in its PacletInfo.m file. It appears that that causes the paclet to be loaded on the service kernel as well (tested with a clean 12.3 version) $\endgroup$
    – Lukas Lang
    Commented Oct 23, 2021 at 10:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.