¿Qué es el proceso "secd"?

19

Me pregunto qué secdproceso hace bajo OSX Yosemite. Estoy bastante seguro de que he visto este proceso ejecutándose en versiones anteriores de MacOS, pero no recuerdo haber engullido toda la memoria disponible tan audazmente ...

Tengo tres computadoras con Yosemite, cada una con una configuración diferente. Los tres han estado despiertos por una duración de tres días a una semana. Aquí hay un resumen de lo que se secdha logrado:

  • En MacBookAir 2011 con 4 GB de memoria, 700 MB asignados a secd
  • En iMac 2008 con 6 GB de memoria, 2 GB asignados a secd
  • En iMac 2011 con 12 GB de memoria, 4 GB asignados a secd

En las tres computadoras secdes el proceso más grande en la memoria (más grande que kernel task) y sospecho que juega un papel en la desaceleración que he experimentado recientemente con la llegada de Yosemite. Sé con certeza que el proceso se expande en la memoria a tamaños excesivos y libera memoria cuando lo necesito en otro lugar. El único problema es que no es tan rápido para liberar memoria y la mayoría de las veces el rendimiento sufre antes de que el proceso se dé cuenta de que tiene que retirarse.

Mi búsqueda en la web no llegó a una conclusión sólida en cuanto a cuál es el proceso y por qué debería ser tan grande. Supongo que no soy el único que experimenta esto. Cualquier consejo es apreciado.

Como se sugiere a continuación secdtiene que ver con Apple Keychain. Estos son los archivos y puertos que el proceso mantiene abiertos cuando está activo (en MacBookAir):

/
/usr/libexec/secd
/Users/.../Library/Keychains/7285EFCF-9AF6-53DD-BE44-DA1F59F96620/keychain-2.db-shm
/usr/share/icu/icudt53l.dat
/usr/lib/dyld
/private/var/run/diagnosticd/dyld_shared_cache_x86_64
/dev/null
/dev/null
/dev/null
count=2, state=0x2
/Users/.../Library/Keychains/7285EFCF-9AF6-53DD-BE44-DA1F59F96620/keychain-2.db
/Users/.../Library/Keychains/7285EFCF-9AF6-53DD-BE44-DA1F59F96620/keychain-2.db-wal
/Users/.../Library/Keychains/7285EFCF-9AF6-53DD-BE44-DA1F59F96620/keychain-2.db-shm
/Users/.../Library/Keychains/7285EFCF-9AF6-53DD-BE44-DA1F59F96620/keychain-2.db
/Users/.../Library/Keychains/7285EFCF-9AF6-53DD-BE44-DA1F59F96620/keychain-2.db-wal
/dev/random
/dev/random
/private/var/folders/z_/806bzc396cxgp4s0q17tpfwc0000gn/T/etilqs_y5BDgkbGkBV9ybF
/private/var/folders/z_/806bzc396cxgp4s0q17tpfwc0000gn/T/etilqs_Aw6Q7JhPlil3QNX
/Users/.../Library/Keychains/7285EFCF-9AF6-53DD-BE44-DA1F59F96620/keychain-2.db
/Users/.../Library/Keychains/7285EFCF-9AF6-53DD-BE44-DA1F59F96620/keychain-2.db-wal

Lo que no está claro es qué hace el proceso con toda la memoria que ocupa y por qué se infla tanto.

macos mavericks yosemite memory daemons retrografía
fuente
2
Tu memoria es correcta. secdcorre en Mavericks. En un análisis rápido, este demonio no está documentado, esto es malo, esto podría ser una pieza de crapware. Este demonio está adentro /usr/libexec/secd.
dan
@danielAzuelos ¿Muestra el mismo comportamiento canceroso en Mavericks?
retrografía
2
Según el Plist, secd se usa para administrar el llavero en la nube, no el local.
Ruskes
2
Recién descubierto: sin secdejecutar, Messages me pide una contraseña cada vez.
interestinglythere
1
→ Mah: en Maveriskc, secdtiene un VSZ = 2.4 GB y un RSS = 3 MB. secdfuncionó durante 84 s en un sistema que funciona desde hace 5 días.
dan

Respuestas:

20

Si no es aparente, esto es solo una suposición. Pero con suerte te da algunas pistas.

En primer lugar, esto es lo que puede deducir solo del nombre del programa. Si ejecuta el comando /bin/ls /usr/libexec | sort -f | egrep '.*d$'(esto imprimir todos los archivos /usr/libexecque terminan en d), encontrará ftpd, hidd, networkd, systemstatsd, y una gran cantidad de programas que terminan en d. La "d" significa "daemon", que básicamente significa un proceso auxiliar que siempre se ejecuta en segundo plano. Lo secmás probable es "seguridad". Así secdes el "demonio de seguridad". Lo cual tiene sentido porque dijiste que parece que funciona con cosas de llavero.

¿Cuál es el punto de los demonios? Algunos demonios se mantienen en ejecución para realizar alguna tarea continua. hidd("daemon de dispositivo de interfaz humana"), por ejemplo, es el proceso responsable de manejar la entrada del mouse / teclado / trackpad. Algunos otros demonios hacen algunas tareas comunes que muchos otros programas necesitan. Las aplicaciones simplemente pueden decirle al demonio que haga algo en lugar de tener un código para hacerlo por sí mismo. Entonces, secdprobablemente haga algo como esto, pero relacionado con el llavero.

¿Pero qué exactamente? Parece que en realidad no maneja el uso normal del llavero, ya que aún pude usar el llavero después de deshabilitar el secdLaunchAgent.

Inspeccionar el LaunchAgent nos da una pista:

Parece que secd es responsable de sincronizar el llavero con iCloud?

Entonces, ¿qué debería hacer? Pruebe uno o más de estos:

  1. Si no necesita la sincronización del llavero de iCloud, desactívela en las preferencias de iCloud.
  2. Use launchctlpara deshabilitar secd si no parece afectar negativamente a nada.
  3. Si necesita la sincronización de llavero de iCloud, vea si tiene una tonelada de elementos de llavero y elimine los que no necesita.
  4. Tal vez reconstruya su llavero (haga un nuevo llavero, mueva los elementos que necesite y muévalo sobre el anterior), en caso de que queden artefactos innecesarios en el antiguo llavero.
curiosamente
fuente
Este es un detalle impresionante. El paso 2 debe tener un asterisco: tome nota de que lo desactivó, ya que Apple generalmente agregará alguna característica nueva y su Mac se romperá cuando eso suceda, así que recuerde volver a encenderlo de vez en cuando y volver a revisar la decisión de desactivar Un demonio del sistema.
bmike
Una vez más, una respuesta fantástica que explica cómo aplicar ingeniería inversa a cualquier demonio y no solo a este que no está bien documentado.
bmike
5

El programa / usr / libexec / secd se envía como parte de OS X y es un proceso de seguridad normal. La documentación dice que se relaciona con "políticas de seguridad de tiempo de ejecución para procesos". Puede inspeccionar los procesos asociados con este comando:ps -ef|grep sec[iud]

En mi Mac, soy el usuario 501, por lo que tiene esta salida para un usuario conectado:

Mac:~ bmike$ ps -ef|grep sec[iud]
    0    58     1   0 Sat12PM ??         0:56.51 /usr/sbin/securityd -i
    0   117     1   0 Sat12PM ??         0:00.15 /usr/libexec/secinitd
    0   171     1   0 Sat12PM ??         0:02.24 /usr/libexec/securityd_service
  501   205     1   0 Sat12PM ??         0:11.74 /usr/libexec/secinitd
  501  2634     1   0 Tue08PM ??         0:08.26 /usr/libexec/secd

Puede ver que securitydse inicia como root (PID 58) y luego como un proceso de usuario (PID 205) cuando inicia sesión. El real secdrealiza el "trabajo" y puede reaparecer incluso cuando no se desconecta y se inicia sesión. para descifrar por qué el suyo está utilizando recursos adicionales, será bastante difícil sin profundizar fsusagey algunos otros comandos para echar un vistazo a los procesos en ejecución y revisar sus archivos de registro. Su mejor opción sería presentar un error con Apple y luego documentar cómo puede hacer que se comporte mal, especialmente si puede reproducirlo después de un reinicio.

Actualmente no hay una "página de manual" secdy la secinitdmejor es escasa. Archivar errores de documentación contra Apple es una forma de pedir que se remedia la falta de documentación.

bmike
fuente
3

Por lo que sé sobre ese proceso (que realmente no es una tonelada) es que tiene algo que ver con el llavero de Mac. Lo que puede hacer es buscar en el Monitor de actividad y hacer clic en Cmd + I para obtener la información al respecto.

Un consejo que puede intentar hacer es ejecutar Keychain First Aid yendo a Keychain Access en Spotlight, abriendo el menú "Keychain Access" y seleccionando la opción "Keychain First Aid" desde allí y siguiendo las instrucciones.

Espero que la propina funcione!

jaller200
fuente
¡Los primeros auxilios del llavero dicen que mi llavero está bien! En las tres computadoras.
retrografía
Hay una opción en El Capitán (al menos, también puede estar allí en versiones anteriores) en Acceso a llaveros - Preferencias para restablecer mi llavero predeterminado "Vuelve a los valores predeterminados de fábrica y crea un nuevo llavero de" inicio de sesión "vacío. ser movido a un lado, pero no eliminado ". Tan pronto como hice esto, el securityd_service pasó de 51-53% de CPU a 0-1.5%. Tan pronto como lo haga, deberá volver a iniciar sesión en iCloud; aún no he descubierto otras ramificaciones.
Oskar Austegard el
1
Acabo de actualizar de Mavericks a Sierra y descubrí que la segunda CPU pasó de cerca del 100% después de restablecer el llavero como usted sugirió. Perdí todas las contraseñas guardadas de mi sitio web, tuve que volver a iniciar sesión en mi sincronización de calendario, etc., pero al menos puedo usar la computadora nuevamente. Gracias.
Walter Nissen