En las raras ocasiones en que esto me sucedió en el pasado, comencé a jugar con dtrace scripts para saber qué está pasando. Un script listo para usar es opensnoop .
Por lo tanto, la próxima vez que tenga este problema, juegue con él de la siguiente manera:
$ sudo opensnoop -ve
o limitando la salida a lo que esperas:
$ sudo opensnoop -ve | grep -i chrome
Es posible que los procesos de corta duración no se muestren en su salida ps , por lo que otra opción es para nosotros el marco de seguimiento de límites de función disponible para dtrace . Probablemente, su versión de OSX tendrá puntos de entrada simples definidos para la capa VFS (llámela 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));
}
Llamarlo es similar al anterior:
$ sudo dtrace -s dump_vfs.d
El comando fs_usage puede lograr una hazaña funcionalmente cercana, especialmente si sospechas que dicho proceso está colgado en un bucle de eventos, aunque aún acceda a la capa fs mediante llamadas al sistema.
Esto podría ser un poco excesivo, ya que la opción más pragmática probablemente es presionar el botón de encendido. Como mencionó que envió un informe a Apple, es posible que desee revisarlo nuevamente en las siguientes ubicaciones:
~/Library/Logs/DiagnosticReports/
/Library/Logs/DiagnosticReports/
Esto debería proporcionarle sugerencias adicionales sobre por qué dicha aplicación se bloqueó de tal manera.
Su curiosidad con respecto al sistema operativo que maneja tales situaciones probablemente se puede apagar parcialmente al buscar en las fuentes del kernel XNU en bsd/kern/kern_shutdown.c . En algún momento, el proceso de apagado iniciado a través del Finder se ejecutará en un tiempo de espera, que luego registrará los intentos de SIGTERM fallido (extracto de mi versión local 2782.1.97 copia de las fuentes del núcleo de 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 la aplicación Console podría mostrarle las entradas de registro relevantes. Dependiendo de una posible situación de bloqueo en vivo con respecto a un archivo que se mantiene en una partición montada en la 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 algunas configuraciones de tiempo de espera de montaje VFS.
Como una nota al margen: tuve muy poca alegría con Chrome en mi MBP, principalmente porque creo que las actualizaciones recientes del controlador central de nvidia dentro de OSX >= 10.9 junto con funciones de administración de energía elevadas y ahora appnap, combinado con avances recientes en la administración del plugin shockwave de dicho navegador, causó repetidamente el caos. Además de eso, Chrome en 2014 fue el que más hambriento de todos los navegadores.
Probablemente haya media docena más de escenarios por los que recibió esta interfaz gráfica de usuario sin comentarios. Ninguno de los cuales se acerque ni remotamente a los problemas que mencionó brevemente al mencionar Win95 :).
¡Solo presiona el botón de encendido, ya!
