Sonic Pi Boot Error


#1

macOS 10.14 Mojave
Sonic Pi 3.1.0

Hello, I’ve just run into the dreaded Boot Error when I tried to restart the app. Details are at https://github.com/samaaron/sonic-pi/issues/1972

I expect rebooting the machine will sort it but I guess this shouldn’t happen.

Thoughts?


#2

Yeah,

it looks like part of the app is still running behind the scenes. I try my best to make sure this doesn’t happen with careful boot and shutdown code, but if things abort incorrectly this can happen.

You either need to kill the processes manually via the terminal or just restart.

Sorry for the trouble.


#3

Thanks Sam, how do I kill the processes manually via the terminal? I’m guessing I do a sudo kill <pid>, but which pid?


#4

Hi Carl

I usually find it easiest to use the Activity Monitor (in the Applications utilities folder). If you then sort the display into pid order you get something like this for a running Sonic Pi. (I’ve highlighted the relevant pids).
You can then force quit them from the Activity screen. Of course the actual pid numbers you get will be differnt, but they should be fairly close to each other numerically).
If things haven’t gone correctly on exit (where Sonic Pi should quit all of these) you may find one or more still running. Often the culprit is Scsynth. I haven’t upgraded to Mojave yet as I still have some Apps I want to use which only run on 32bit builds. On HighSierra I very rarely get problems of this nature, but maybe Mojave introduces some problems.


#5

Hi Robin, the only one of those processes I could find was beam.smp - I deleted that, and now Sonoc-Pi is back to its former glory. Yay! Thanks very much!


#6

That’s great. As expected you would only get the one or two that hadn’t quit properly on the previous run which thus causes Sonic Pi not to load properly on a subsequent re-run That maybe useful info for @samaaron if erl is causing the problem with Mojave.


#7

It is useful to know, although so far Mojave has behaved just normally for me and I haven’t seen any specific issues with Erlang locally. However, I am aware that occasionally some processes can still be ‘zombied’. Unfortunately I’m not quite sure how to tackle this at this point beyond all the work that’s currently happening to deal with it.