MacOS – Rebooting a Mac with a frozen application

google-chromemacos

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…

Best Answer

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_CREATE:entry,
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>",
        stringof(this->name));
}

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:

~/Library/Logs/DiagnosticReports/
/Library/Logs/DiagnosticReports/

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!

Related Question