¿Por qué mis utilidades de línea de comandos se ejecutan tan lentamente en mi Mac?

Acabo de notar que las utilidades de la línea de comandos como ls( /bin/ls), touch( /usr/bin/touch), cat( /bin/cat), etc. son muy lentas cuando las ejecuto desde Terminal o iTerm en mi MacBook. Por ejemplo:

  • ls'ing while en un directorio vacío toma 1 segundo (también toma 1 segundo en un directorio no vacío, tanto con muchos archivos como con pocos archivos);

  • touch'ing un archivo nuevo toma 1 segundo (también toma 1 segundo para touchun archivo existente);

  • cat'ing un archivo vacío toma 1 segundo (también hay un retraso de 1 segundo antes de que suceda algo cuando no tengo catun archivo vacío).

He intentado diagnosticar esto de muchas maneras, pero fue en vano. No creo que esto sea un problema del sistema de archivos, ya que:

  • He ejecutado la Utilidad de Discos y no reporta problemas.

  • Todo parece funcionar bien en Finder, por ejemplo, el contenido del directorio se muestra instantáneamente en Finder.

  • Instalé GNU coreutils usando Homebrew e intenté usar gls, gtouch, gcat, etc., y todas las operaciones que enumeré anteriormente ocurren instantáneamente cuando se ejecutan con la versión GNU.

¿Alguna idea de lo que podría estar pasando? ¿Alguna idea sobre cómo solucionar este problema?


EDITAR: cuando reinicio la computadora o pruebo con un usuario diferente, estos problemas desaparecen temporalmente, pero después de unos minutos parecen volver a aparecer. Otra cosa extraña que noté:

$ time date
Wed Jan 28 10:07:11 PST 2015

real    0m0.151s
user    0m0.001s
sys     0m0.003s

$ time date
Wed Jan 28 10:07:13 PST 2015

real    0m0.029s
user    0m0.001s
sys     0m0.002s

$ time date
Wed Jan 28 10:07:16 PST 2015

real    0m1.005s
user    0m0.001s
sys     0m0.002s

$ time date
Wed Jan 28 10:07:18 PST 2015

real    0m1.005s
user    0m0.001s
sys     0m0.002s

Esto sucede con todas las utilidades que he probado, mkdir, scp, sftp, more, cat, etc.: La primera vez que lo ejecuto después de reiniciar, es medio-lento. La segunda vez que lo ejecuto, es bastante rápido. Todas las veces posteriores que lo ejecuto, es lento.

¿Puedes ejecutar time ls, time touch fooetc. y copiar/pegar el resultado en tu pregunta?
@patrix: Para todos los casos que he enumerado, la timesalida es muy cercana a 0m1.004s reales, 0m0.002s de usuario, 0m0.002s sys, más o menos ~0.001s.
(Mientras que las versiones de GNU tienen alrededor de 0m0.004s reales)
¿Aparece algo extraño en el registro (visible a través de Console.app) cuando ejecuta estos comandos?
@BartArondson -- ¡Gracias por esa sugerencia! Fue a través del registro en Console.app que finalmente pude resolver el misterio.

Respuestas (3)

De hecho, descubrí el problema hoy. Fue causado por un software anti-malware llamado Sourcefire AMP (Advanced Malware Protection) . Todos mis problemas desaparecieron después de que lo deshabilité/desinstalé.

Supongo que estaba haciendo algo como retrasar cosas en /bin, /usr/bin, etc. por "razones de seguridad"... Supongo que las herramientas GNU no se retrasaron porque no estaban en los directorios "en la lista negra".

Me alegro de que lo hayas descubierto. Siéntase libre de aceptar su propia respuesta; puede ayudar a otros a resolver el mismo problema.
La página www.sourcefire.com no funciona. Actualmente, www.sourcefire.com no puede manejar esta solicitud. ERROR HTTP 503

Lo primero que verificaría es que no tenga un $PATH extraño: ejecute los tiempos de un archivo que no existe y uno que debería ser rápido:

Mac:~ bmike$ time /bin/ls /private/xyz
ls: /private/xyz: No such file or directory

real    0m0.004s
user    0m0.001s
sys     0m0.002s

Mac:~ bmike$ time /bin/ls /private/tmp
com.apple.launchd.q2QmVhsPCV    com.apple.launchd.zQ5EK6R6AZ

real    0m0.006s
user    0m0.002s
sys     0m0.003s

Lo siguiente sería verificar el negocio general del sistema:

Mac:~ bmike$ vm_stat 5
Mach Virtual Memory Statistics: (page size of 4096 bytes)
    free   active   specul inactive throttle    wired  prgable   faults     copy    0fill reactive   purged file-backed anonymous cmprssed cmprssor  dcomprs   comprs  pageins  pageout  swapins swapouts
  306160  1168138    79266    53096        0   299239   613825 20971811   345367 15995721      237  2472732      203216   1097284   328691   190541   260034   646113   623838      285   286101   299172 
  305613  1172072    79345    53098        0   295915   618898     1191        1      680        0        0      203297   1101218   328691   190541        0        0        0        0        0        0 
  306163  1188285    79345    53088        0   279370   621180     1055        0      600        0        0      203287   1117431   328682   190541        9        0        0        0        0        0 
  306039  1186031    79345    53088        0   281598   621176      729        0      293        0        0      203287   1115177   328664   190541       18        0        0        0        0        0 
^C
Mac:~ bmike$ iostat 5
          disk0       cpu     load average
    KB/t tps  MB/s  us sy id   1m   5m   15m
   31.31  12  0.35   9  4 86  1.32 1.41 1.43
    0.00   0  0.00   2  2 96  1.21 1.38 1.42
   18.40   1  0.02   5  2 93  1.20 1.38 1.42
   22.00   1  0.02   3  2 95  1.20 1.38 1.42
^C

Luego saldría de todas las aplicaciones, cerraría la sesión de todos los usuarios y reiniciaría. Si tiene su Mac inicia sesión, deshabilítelo en las preferencias del sistema para que pueda realizar un inicio de sesión seguro después del reinicio. (Mantenga presionada la tecla shift inmediatamente después de presionar regresar si escribe una contraseña para iniciar sesión en su usuario o mantenga presionada la tecla shift justo después de seleccionar su ícono de usuario si no tiene una contraseña).

Repita las mediciones (y, opcionalmente, cronometre las herramientas gnu alternativas) para saber si el problema es temporal o sistemático.

Inicie sesión también como invitado o como nuevo usuario y repita el tiempo
time /bin/ls /non/existent/directoryes lento. time /bin/ls /bines lento.
He actualizado mi pregunta con algunos detalles más...

Similar a lo que dijo @bmike, su $PATH podría tener algo que hace que el shell se demore antes de encontrar el comando que está tratando de ejecutar. Además del datecomando, timetambién debe nombrarse explícitamente en la línea de comando.

Pruebe /usr/bin/time /bin/datey time datevarias veces seguidas para ver si hay alguna diferencia en la salida. Si es así, echo $PATHdebería darte una pista de qué está causando el retraso.

timees a la vez un shell (bash) incorporado y un binario, podría ser mejor ceñirse a uno en todos los casos.
Interesante. Pensé que timesestaba incorporado, pero no time. Sin embargo, no puedo hacer que timedeje de funcionar, incluso después de destruir mi $ PATH ... así que probablemente tengas razón. Sin embargo, comparar la salida de times /bin/datey times datepodría ser la mejor opción en general porque timeses un hecho inequívoco. (Curiosamente, time date, times datey /usr/bin/time datedevuelven tres salidas con formato diferente)
También puede usar type timepara averiguar de dónde proviene un comando :-)