I have just realized I do not know how OS X manages applications.

Today Google Chrome froze on my OS X Yosemite 10.10.2. After it froze, I simply quit it using "Force quit". I have even sent a report to Apple.

The Dock kept showing it as 'running', but clicking on "Force quit" did not have any effect. I restarted both the Finder and the Dock, but Chrome kept showing as 'running'. However, no process reminding me of 'Chrome' was listed in Activity Monitor or in ps aux in a Terminal.

So I decided to restart my machine and it was embarrassing: enter image description here

So I was rebooting because Chrome was not responding, but my machine refused to reboot because I had to quit Google Chrome first, which was not among the running processes. Luckily, Apple has not yet removed the power button from their laptops.

When does this happen? Which "lock" file do I need to remove for telling OS X that a 'running' application is in reality not running?

PS. Isn't this a MS Windows 95-like behaviour? What a pity...

  • In this situation, another way to forcibly quit Chrome (and its associated tab processes) is to open Terminal.app and run the following command: killall 'Google Chrome' (careful, those single quotes are necessary). This kills the targeted process(s) with a TERM signal. Whether this will work when "Force Quit" has somehow failed, I'm not entirely sure (but killall should always work). Commented Apr 24, 2015 at 18:24
  • Thank you. But where does that information stay in the OS? I mean: no process in "ps aux" had something vaguely connected with Chrome. My question is not only about how to recover in those situations: I would really like to understand how the OS manages app launching and killing. Commented Apr 24, 2015 at 21:22
  • This is probably an extreme situation. My guess is that killing ("Force Quit") Google Chrome does not kill all "Google Chrome Helper" processes, maybe the original problem was that one of them go bonkers and was detached as child of main GC process. If this is true the solution could be manually Force Quit all "Google Chrome Helper" processes remaining.
    – DavAlPi
    Commented Apr 25, 2015 at 18:27
  • Yeah, but how do you kill them if no references to Google Chrome or its helper processes are returned by ps or Activity Monitor? Considering how bad the Apple file system is, don't you think it could be related to a file which remains hanging somewhere?. Commented Apr 26, 2015 at 14:36

1 Answer 1


In the very rare occasion this has happened to me in the past, I started fiddling around with dtrace scripts to know what's going on. One ready to use script is opensnoop.

So, the next time you hit this issue, toy around with it as follows:

$ sudo opensnoop -ve

or limiting the output to what you'd expect:

$ sudo opensnoop -ve | grep -i chrome

Short-lived processes might not show up in your ps output, so another option is to us the function boundary tracing framework available to dtrace. Most probably, your OSX version will have simple entry points defined for the VFS layer (call it dump_vfs.d):

#!/usr/sbin/dtrace -s

#pragma D option quiet
#pragma D option switchrate=10hz

dtrace:::BEGIN {
    printf("%-12s %6s %6s %-12.12s %-12s %s\n", "TIME(ms)", "UID",
        "PID", "PROCESS", "CALL", "DIR/FILE");

fbt::VNOP_REMOVE:entry {
    this->path = ((struct vnode *)arg0)->v_name;
    this->name = ((struct componentname *)arg2)->cn_nameptr;
    printf("%-12d %6d %6d %-12.12s %-12s %s/%s\n",
        timestamp / 1000000, uid, pid, execname, probefunc,
        this->path != NULL ? stringof(this->path) : "<null>",

Calling it is similar to above:

$ sudo dtrace -s dump_vfs.d

A functionally close feat can be achieved by the fs_usage command, especially if you suspect said process to be hanging in an event loop, though still accessing the fs layer using system calls.

This might be a bit of an overkill, since the most pragmatic choice is probably hitting the power button. Since you mentioned that you sent a report to Apple, you might want to check it out again under the following locations:


This should give you additional pointers as to why said application crashed in such a way.

Your curiosity with regard to the OS handling such situations can probably be partially quenched by looking into the XNU kernel sources at bsd/kern/kern_shutdown.c. At some point, the shutdown process initiated via Finder will run into a timeout, which then logs the attempts of failed SIGTERM (extract from my local version 2782.1.97 copy of the Darwin kernel sources):

    for (p = allproc.lh_first; p; p = p->p_list.le_next) {
        if (p->p_shutdownstate == 1) {
            printf("%s[%d]: didn't act on SIGTERM\n", p->p_comm, p->p_pid);
            sd_log(ctx, "%s[%d]: didn't act on SIGTERM\n", p->p_comm, p->p_pid);

This indicates that the Console application might show you the relevant log entries. Depending on a potential live lock situation regarding a file held on a network mounted partition which just lost its layer 1 signal, the kernel will enter a wait loop of 100 to 200 seconds, depending on some VFS mount timeout settings.

As a sidenote: I had very little joy stability-wise with Chrome on my MBP, mainly because I believe recent updates to the nvidia core driver inside OSX >= 10.9 together with elevated power management functionalities and now appnap, combined with recent advances in the shockwave plugin management of said browser, repeatedly caused havoc. On top of that, Chrome in 2014 for me was the most power hungry of all browsers.

There are probably half a dozen more scenarios as to why you were greeted with this unmotivated feedback GUI. None of which come even remotely close to the issues you briefly referred to by mentioning Win95 :).

Just hit the power button, already!

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .