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?
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.
Thanks Sam, how do I kill the processes manually via the terminal? I’m guessing I do a sudo kill <pid>, but which pid?
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.
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!
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.
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.
ps -fe | egrep -i 'sonic|ruby|scsynth|beam.smp|erl_child|o2m|m2o' | awk '{print $2}' | xargs kill
Cool! I’m guessing that does a list of running processes, filters by any name in the | delimited list, prints out the name and then kills the process. It certainly zaps Sonic-Pi. This is what it gives me…
pizap
kill: 1: Operation not permitted
[1] 9530 done ps -fe |
9531 done egrep -i 'sonic|ruby|scsynth|beam.smp|erl_child|o2m|m2o' |
9532 done awk '{print }' |
9533 terminated xargs kill
Any idea why it comes up with “Operation not permitted”?
Hmm … not sure, which operating system are you on? Maybe it doesn’t work everywhere out of the box.
How I’d debug this:
[tgrosser ~]$ ps -fe | head
UID PID PPID C STIME TTY TIME CMD
0 1 0 0 1Nov18 ?? 6:56.22 /sbin/launchd
0 61 1 0 1Nov18 ?? 0:33.68 /usr/sbin/syslogd
We need to find the PID (process ID) which can be used to kill processes. Since it’s in the 2nd column you get it using the awk command.
[tgrosser ~]$ ps -fe | egrep -i 'sonic|ruby|scsynth|beam.smp|erl_child|o2m|m2o' | awk '{print $2}'
29271
29286
...
Actually it’s good you cannot kill process number 1, b/c you could zap your running system that way, which is kind of bad 
I’m on macOS 10.14 Mojave.
That’s proabaly why when I tempoaraily changed the command to ps -fe | egrep -i 'sonic|ruby|scsynth|beam.smp|erl_child|o2m|m2o' | awk '{print $2}' | sudo xargs kill it made my system spontaneously reboot 
ouch … sorry for that 
I was glad it worked w/o sudo
LOL! Don’t apologise! It’s my fault for being [a] Too inexperienced and [b] Too impetuous for my own good 