Por @Alvy — 17 de diciembre de 2007

Alabados sean Rosyna de Unsanity y Merlin de 43 folders por haber publicado la solución al bug más porculero de todos los que he venido sufriendo en el último año en mi Mac. El caso es que llevaba desde antes del verano malviviendo con él, pero como no era vital y había pseudosoluciones (y sólo afectaba a un equipo, no a todos) lo había dejado pasar. Alguna vez intenté mirar si había soluciones, pero nada. Metódicamente instalaba las revisiones de sistema a ver si eso lo arreglaba, pero tampoco. Pero he aquí que hoy por fin investigo un poco más y me encuentro que desde enero existía la solución. Así que la comparto por si alguien más la ha sufrido y puede resolverlo.

El problema tiene que ver con las autorizaciones a a las contraseñas del Llavero en Mac OS X. El síntoma es que cuando el sistema pide autorización para usar/cambiar las contraseñas de algunas aplicaciones y se elige «Permitir», tarda muchísimo en hacerlo (cuando debería ser casi instantáneo). Entonces el Mac comienza a ir más y más lento, hasta casi congelarse. Si se mira en el Monitor de Actividad, aparece un proceso llamado securityd que está consumiendo cantidades ingentes de memoria, más de 1,5 GB. El desastroso final suele ser que el equipo se bloquea y hay que reiniciar.

La solución de baja tecnología es no usar el Llavero o decir siempre «Denegar» cuando pide permiso. No está claro si afecta a todas las aplicaciones o solo a algunas, pero es especialmente molesto al usar NetNewsWire y Transmit. También se da mucho al actualizar de versión cualquier aplicación, pues aparece el mensajito de «actualizar las llaves» y ahí surge el problema.

Al parecer afecta sin que esté muy claro por qué al sistema 10.4 y 10.5. A mi me fallaba en el iMac Core Duo, mientras en el viejo G5 y en G4 nunca he tenido el problema. El bug tiene que ver con un fichero de datos/configuración corrupto de securityd, que es el demonio que gestiona la autorización de las contraseñas y llaves entre el sistema y las apliaciones.

La solución e investigación completa está aquí: Love Tropicana: The Fix for securityd Eatings Gobs of Ram When Updating Keychain Entries con algunos comentarios adicionales en Fix for securityd hogging RAM when reauthorizing apps’ Keychain access. Básicamente se resume en abrir el Terminal y teclear:

sudo mv /var/db/CodeEquivalenceDatabase /var/db/CodeEquivalenceDatabase.old

(Pedirá la contraseña de administrador). Esto renombra el fichero CodeEquivalenceDatabase que es lo que está corrupto, de modo que el sistema lo regenerará la siguiente vez que lo necesite.

La primera vez intenté este arreglo no me funcionó, pero hacer esto seguido de un Reiniciar al ordenador sí que lo hizo.

Los interesados en investigar más el porqué del asunto y de cómo funciona el arreglo, o intentar variantes (con cautela) pueden revisar el artículo original.

Compartir en Flipboard Publicar / Tuitear Publicar