En la rarísima ocasión en que esto me ha sucedido en el pasado, empecé a juguetear con dtrace scripts para saber qué está pasando. Uno de los scripts scriptslistos para usarscriptses opensnoop .
Así que, la próxima vez que te encuentres con este problema, juega con él de la siguiente manera:
$ sudo opensnoop -ve
o limitando la salida a lo que se espera:
$ sudo opensnoop -ve | grep -i chrome
Los procesos de corta duración pueden no aparecer en su ps por lo que otra opción es utilizar el marco de rastreo de límites de funciones disponible para dtrace . Lo más probable es que su versión de OSX tenga definidos puntos de entrada simples para la capa VFS (llámese 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));
}
La llamada es similar a la anterior:
$ sudo dtrace -s dump_vfs.d
Una hazaña funcionalmente cercana puede lograrse con el fs_usage especialmente si sospecha que dicho proceso está colgado en un bucle de eventos, aunque sigue accediendo a la capa fs mediante llamadas al sistema.
Esto podría ser un poco exagerado, ya que la opción más pragmática es probablemente pulsar el botón de encendido. Ya que mencionaste que enviaste un reporte a Apple, tal vez quieras revisarlo de nuevo en los siguientes lugares:
~/Library/Logs/DiagnosticReports/
/Library/Logs/DiagnosticReports/
Esto debería darle indicaciones adicionales sobre por qué dicha aplicación se bloqueó de tal manera.
Su curiosidad con respecto al manejo de tales situaciones por parte del sistema operativo puede ser parcialmente saciada buscando en las fuentes del kernel de XNU en bsd/kern/kern_shutdown.c . En algún momento, el proceso de apagado iniciado a través de Finder se encontrará con un tiempo de espera, que luego registra los intentos de SIGTERM fallidos (extraído de mi copia local de la versión 2782.1.97 de las fuentes del kernel Darwin):
[...]
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);
}
}
[...]
Esto indica que el Console la aplicación puede mostrarte las entradas de registro pertinentes. Dependiendo de una situación potencial de bloqueo en vivo con respecto a un archivo mantenido en una partición montada en red que acaba de perder su señal de capa 1, el kernel entrará en un bucle de espera de 100 a 200 segundos, dependiendo de algunos ajustes de tiempo de espera de montaje VFS.
Como nota al margen: he tenido muy pocas alegrías en cuanto a estabilidad con Chrome en mi MBP, principalmente porque creo que las recientes actualizaciones del controlador de núcleo de nvidia dentro de OSX >= 10.9 junto con las elevadas funcionalidades de gestión de energía y ahora appnap, combinadas con los recientes avances en la gestión de plugins de shockwave de dicho navegador, causaron estragos en repetidas ocasiones. Además de eso, Chrome en 2014 para mí fue el más hambriento de energía de todos los navegadores.
Probablemente hay media docena más de escenarios en cuanto a por qué fuiste recibido con esta GUI de retroalimentación desmotivada. Ninguno de los cuales se acerca ni remotamente a los problemas a los que se refirió brevemente al mencionar Win95 :).
¡Dale al botón de encendido, de una vez!
