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!
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 (butkillall
should always work).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?.