I’ve replaced the old HDD of my late 2008 unibody MacBook (8 GB of RAM, running OS X 10.7.4) with an OCZ Vertex 3 SSD. After doing this, I've installed Lion and restored my data from a Time Machine backup.

Everything is fine, except for a process named “bash” that permanently uses about 90 % CPU.

If I kill it via Activity Monitor, everything goes back to normal, but unfortunately the process comes back every time I restart the computer.

I've tried do zap the PRAM, reinstall 10.7.4 from the combo package, and even simply wait for more than 2 hours, but the problem is still here.

  • Which user runs that process? What additional information do you get through Activity Monitor? Anything particular in ps -ef about it? – slhck May 12 '12 at 19:49
  • 1
    It comes straight from my account. / /bin/bash /usr/lib/dyld /private/var/db/dyld/dyld_shared_cache_x86_64 /dev/null ->0xffffff8012ae4810 ->0xffffff8012ae4810 ->0xffffff8011d30180 /usr/bin/stkLaunchAgent.sh – Sano May 12 '12 at 20:06
  • Hmm... you should check out what is with that stkLaunchAgend.sh . From Google, STK could be some Oracle thing, some game (Super Tux Kit), for different development frameworks (Synthesis ToolKit, Standard Templating Kit). That dyld is the dynamic linker, which has something to do with loading libraries. Maybe you have some problems with the alternate caching of a process or something. I'm no expert, but I hope I gave you a lead. – user127350 May 12 '12 at 20:50
  • 1
    I have exactly same issue, and I realize the stkLaunchAgnet.sh come form an app call "Send to Kindle".Problem solved after I uninstall "Send to Kindle" by it's uninstaller. – taiansu May 31 '12 at 18:15
  • 1
    Whoever wonders what stkLaunchAgent is: This script is part of Amazon's "Send To Kindle" app. – freytag Oct 28 '15 at 5:26

bash is the standard shell under OS X – meaning it is the standard program to interface with the operating system’s Darwin underpinnings (technically, /bin/sh is the standard shell, but that has been a copy of /bin/bash since OS X 10.3). It is the process that is launched when you open a Terminal.app window – an interactive shell.

bash can also be launched without a terminal window – a non-interactive shell –, for instance to execute shell scripts, often denoted by the file suffix .sh. That is the case here – bash is running the script /usr/bin/stkLaunchAgent.sh, and something in this script is keeping your system busy.

Now, /usr/bin/stkLaunchAgent.sh is not part of an OS X install – it is some kind of third party addition and as such is not present on my system, meaning I can only guess, but I’d say:

  • from its name part “LaunchAgent” and the fact it starts with your system, that it is triggered by a LaunchAgent – a small definition file used by OS X’ launchd, the system mechanism for starting scripts and non-interactive programs on schedule, boot or other events. That part I‘d qualify as an educated guess.
  • from the fact your troubles began with the installation of your Vertex SSD, and the fact that the crucial difference between SSDs and HDs is the first do not take kindly to defragmentation and similar low-level interventions into their structure, that the script launched by the agent in question might be trying to do some operation on the drive the Vertex SSD does not accept – which keeps the script running and bash busy. Now, that part is only a wild, wild guess, but…

How to find out what the script does:

Open a Terminal window and do open -e /usr/bin/stkLaunchAgent.sh to have a peek into the shell script (that command will open it in TextEdit – terminate it in Activity Monitor first) – that should give you the means to see what exactly is running.

How to get rid of it:

You’ll have to get rid of the LaunchAgent, if it is indeed one. launchd LaunchAgent files are in plist format and found in

  • ~/Library/LaunchAgents – for the current user account only
  • /Library/LaunchAgents – for all user accounts
  • /System/Library/LaunchAgents – system level agents (should not by rights be found here!)

They are usually named in reverse domain notation (tld.domain.process.plist). Depending if the user account of your runaway bash is yours or not, you should look in one of the first two locations above for a likely plist (if you have Xcode installed, you can QuickLook them easily). The correct procedure to stop it is to remove it from launchd’s process list through

launchctl unload tld.domain.process

which will unload and stop the process (note you omit the plist suffix).

There is also a GUI for handling launchd files, Peter Borg’s Lingon (make sure to get “Lingon”, not “Lingon 3”, which is a dumbed down version safe for vanilla use), which might be more convenient than manually rooting through the file locations.



I looked inside the file and learned its part of the Save to Kindle application that I installed a few weeks ago. The app has an uninstaller in /Applications, so I did that instead of deleting the .sh directly. Worked.

  • Uninstalling Save to Kindle fixed this for me too. The cause seems to be a combination of that app and restoring from a Time Machine backup on Lion, because it was working fine for weeks and it was only after I migrated to a new laptop using Time Machine that the problem began. – coco9nyc Jun 18 '12 at 1:18
  • 1
    Removing the "Send to Kindle" program will indeed solve the problem. If you want to continue to use the program reinstall it again and it should work fine with the SSD. I had to restore my system with Time Machine and the bash process/issue returned. Once I reinstalled the program it no longer presented itself. – user141049 Jun 19 '12 at 13:53
  • Same issue here, good find. I uninstalled and the prob went away, fan stopped spinning and computer cooled down. I then re-installed and things are fine. – newz2000 Jun 20 '12 at 13:30

I had the same problem after migrating my system to a Crucial M4 SSD. I "solved" it by deleting /usr/bin/stkLaunchAgent.sh as there were no launch demons directly related to the file.

I'd still like to know where that file came from and why this occurred...


I solved the same problem on my computer by using chown to own the communication pipe present in /var/spool/stkPrinter/username/stkPipe.

The problem occurs because the ownership (maybe the permissions too?) of the pipe changes after migrating to a new drive. The script /usr/bin/stkLaunchAgent.sh does have some basic permission/ownership checking built in, but it obviously doesn't do it well enough. It ends up in the while true loop trying to access the pipe and the logs get completely overtaken by error messages.

I wouldn't even have noticed this if I didn't notice that my Time Machine backups were being inexplicably large, that's when I looked at the system logs and saw millions of lines complaining about the same thing. The log file /var/spool/stkPrinter/username/stkPrint.log was 15GB large!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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