Cómo usar LaunchAgents y LaunchDaemons en macOS: guía completa

En macOS, gran parte de la magia sucede entre bambalinas gracias a servicios que se inician sin que te enteres, y el binomio LaunchAgents/LaunchDaemons es el corazón de esa automatización. Si alguna vez te preguntaste cómo hacer que un script arranque solo, mantener viva una app crítica o auditar lo que cargan las aplicaciones, aquí tienes la guía práctica que estabas buscando.

Desde macOS 13, Apple cambió las reglas del juego con una estructura nueva en los paquetes de apps y el marco de SMAppService, que aporta más transparencia al usuario y una gestión coherente de elementos de inicio de sesión, launch agents y launch daemons. Además, hay mejoras para administradores con perfiles de configuración y herramientas de diagnóstico que conviene dominar.

Qué son launchd, LaunchAgents y LaunchDaemons

El proceso launchd se inicia justo después del kernel (es de los primeros en alzarse, con PID 1 habitualmente) y es quien lanza, controla y supervisa otros servicios. Normalmente consume pocos recursos, pero si un día lo ves subido en el Monitor de Actividad, un reinicio suele devolverlo a la normalidad.

Los LaunchDaemons se ejecutan al arrancar el sistema y lo hacen en contexto de root; no dependen de que nadie inicie sesión y no pueden interactuar con la interfaz gráfica. Son perfectos para tareas del sistema, procesos persistentes y servicios que deben estar disponibles incluso sin usuario conectado.

Los LaunchAgents se cargan al iniciar sesión de un usuario concreto y sí pueden interactuar con la interfaz (barra de menús, notificaciones, ventanas…). Son ideales para utilidades del usuario, asistentes de apps y procesos que requieren sesión iniciada.

En ambos casos, la configuración reside en archivos .plist con claves y valores que indican qué ejecutar, cuándo y cómo. Esos .plist los gestiona launchd y viven en ubicaciones concretas del sistema, por lo que saber dónde van, con qué permisos y cómo cargarlos es crucial.

Estructura y ubicación de los .plist

macOS organiza los .plist de la siguiente forma: a nivel de sistema en /System/Library/LaunchAgents y /System/Library/LaunchDaemons, a nivel global en /Library/LaunchAgents y /Library/LaunchDaemons, y a nivel de usuario en ~/Library/LaunchAgents. La norma sana es instalar lo propio en /Library o en ~/Library, y no tocar el árbol de /System/Library.

Los .plist son archivos XML con claves como Label (identificador del servicio), Program o ProgramArguments (qué ejecutar), RunAtLoad (arrancar nada más cargarse) o KeepAlive (política de reintento/vida). Puedes verlos con un editor de texto, pero edítalos con cuidado y siempre sabiendo qué hace cada clave.

Para que launchd acepte un .plist, hay que respetar propiedad y permisos. Como administrador: sudo chown root:wheel /Library/LaunchAgents/mi.servicio.plist y sudo chmod 644 /Library/LaunchAgents/mi.servicio.plist. Estos ajustes garantizan que root pueda escribir, el grupo wheel y los demás puedan leer, y que launchd confíe en el archivo.

Una vez instalado, se carga con sudo launchctl load -w /Library/LaunchAgents/mi.servicio.plist o su homólogo en /Library/LaunchDaemons. Para retirarlo, puedes usar launchctl remove com.ejemplo.mi-servicio (donde la etiqueta corresponde al valor de Label).

Novedades desde macOS 13: SMAppService y transparencia para el usuario

Apple introdujo una estructura de paquete de app que mantiene los ejecutables de ayuda dentro de la propia app y los gestiona con SMAppService. Esto permite registrar y controlar elementos de inicio de sesión, launch agents y launch daemons como ejecutables auxiliares, sin esparcirlos por el sistema y con más visibilidad para el usuario.

Cuando se implementan estos elementos a través de MDM o instaladores, macOS 13+ muestra una notificación de instalación de elementos gestionados para informar y permitir su revisión en Ajustes del Sistema. La primera coincidencia con una regla genera aviso; las siguientes coincidencias ese mismo día ya no emiten notificaciones repetidas.

Si el usuario aplaza el aviso, macOS silencia más notificaciones de este tipo durante el periodo elegido (1 día o 1 semana). Mientras la notificación está visible, no aparece otra; si se cierra, las instalaciones posteriores vuelven a notificar. Esta política reduce ruido y a la vez ofrece control.

Visibilidad y diagnóstico: todo lo que debes revisar

Para ver qué se está registrando con el nuevo marco, abre Ajustes del Sistema > General > Elementos de inicio. Ahí verás los elementos de inicio de sesión y de fondo; el botón de información te muestra el ejecutable que se lanza y detalles asociados.

En línea de comandos, tienes varias utilidades. Con launchctl list obtienes todos los servicios en ejecución. Para el marco de tareas en segundo plano, usa sfltool dumpbtm y revisa el estado actual (incluye los UUID de la carga útil de servicemanagement). Si necesitas limpiar el estado entre pruebas, ejecuta sfltool resetbtm y, por higiene, reinicia el Mac antes de volver a probar.

Para logs en tiempo real, filtra en Consola por el subsistema y la categoría adecuados, o lanza en Terminal: log stream --debug --info --predicate "subsystem == 'com.apple.backgroundtaskmanagement' AND category == 'mcx'". Con esto verás trazas útiles sobre alta, baja y gestión de los ítems.

Si tienes acceso a AppleSeed for IT, la herramienta Mac Evaluation Utility 4.3.0+ genera reportes detallados en la línea de lo que arroja sfltool dumpbtm, y permite exportar resultados delimitados para análisis posteriores o correlación con inventario.

Perfiles XML para administrar tareas en segundo plano

Las organizaciones pueden aprobar automáticamente elementos de fondo mediante un perfil de configuración XML. El contenido es un array de reglas (diccionarios); cuando un elemento coincide, queda aprobado. Se contemplan varios tipos de coincidencia que conviene dominar.

• BundleIdentifier (ID de paquete) con coincidencia exacta para una app concreta.
• BundleIdentifierPrefix para autorizar familias de apps bajo un prefijo.
• TeamIdentifier del desarrollador (firma de código) con coincidencia exacta.
• Label del servicio (clave Label del .plist de launchd) con coincidencia exacta.
• LabelPrefix para aprobar etiquetas que empiecen por un patrón dado.

Con este enfoque, los administradores garantizan que los elementos legítimos se activen sin fricción, todo con trazabilidad y cumpliendo la política corporativa. Si gestionas flotas, esto te ahorra soporte y evita bloqueos innecesarios.

Seguridad, malware y atribuciones del sistema

Muchos instaladores añaden .plist que al desinstalar la app original quedan olvidados. Ese residuo puede volver a lanzar procesos que creías eliminados. Además, el malware abusa de LaunchAgents para persistir, recolectar datos y comunicarse con servidores remotos.

Apple mantiene un fichero de atribuciones con binarios auxiliares comunes que ayudan a identificar quién es quién: /System/Library/PrivateFrameworks/BackgroundTaskManagement.framework/Versions/A/Resources/attributions.plist. Consultarlo puede darte pistas para atribuir ejecutables a sus apps matriz en análisis forense o limpieza.

Como capa de vigilancia «artesanal», puedes activar Acciones de carpeta sobre rutas sensibles: /Library/LaunchAgents, /Library/LaunchDaemons, /System/Library/LaunchAgents, /System/Library/LaunchDaemons y ~/Library/LaunchAgents. Así recibirás un aviso cuando aparezca un nuevo .plist y podrás inspeccionarlo al vuelo.

Crear tus propios LaunchAgents y LaunchDaemons

La idea base es sencilla: redacta un .plist con el Label (p. ej., com.ejemplo.miscript), define Program o ProgramArguments con la ruta exacta del ejecutable/script, ajusta claves como RunAtLoad y, si procede, KeepAlive, y colócalo en la carpeta adecuada.

Si la tarea debe correr antes del inicio de sesión y sin UI, ubícala en /Library/LaunchDaemons. Si depende de un usuario y/o interactúa con la interfaz, usa /Library/LaunchAgents o ~/Library/LaunchAgents (solo para ese usuario). Recuerda aplicar propiedad y permisos correctos antes de cargar.

Para activar al momento: sudo launchctl load -w /Library/LaunchDaemons/com.ejemplo.miscript.plist. Para detener y descargar: sudo launchctl unload -w /Library/LaunchDaemons/com.ejemplo.miscript.plist o launchctl remove com.ejemplo.miscript. Asegúrate de que las rutas a binarios existan y sean ejecutables.

Consejo práctico: prueba siempre primero en ~/Library/LaunchAgents con tu usuario, verifica logs y comportamiento, y solo después promueve a /Library. Evita modificar /System/Library/…; además de ser mala práctica, el sistema protegido (SIP) lo impide por seguridad.

Políticas KeepAlive y casos de uso reales

Si necesitas que un proceso se mantenga siempre arriba, la clave KeepAlive te permite granularidad. Puedes poner <true/> para reintentos incondicionales o usar un diccionario con condiciones para un control fino.

Un patrón muy útil combina KeepAlive con SuccessfulExit. Cuando defines SuccessfulExit = false, launchd reintentará si el proceso sale con código diferente de 0 (crash, error), pero si el usuario lo cierra «limpiamente» (salida 0), no lo relanzará. Así evitas peleas al actualizar una app o apagar el Mac.

Otro enfoque habitual es NetworkState: si lo estableces a true dentro de KeepAlive, el relanzamiento respetará que «la red esté disponible» (el equipo tenga IP). Ojo: que haya red no siempre significa que haya Internet; launchd solo verifica conectividad básica, no que tu ISP responda.

Si planeas mantener viva una app de interfaz (por ejemplo, una utilidad de barra de menús), crea un LaunchAgent con su binario real del paquete: p. ej., /Applications/MiApp.app/Contents/MacOS/MiApp. Evita rutas a alias o a la app «icónica» y apunta al ejecutable dentro del paquete.

En entornos sin supervisión (kiosco, pantallas informativas, servidores con sesión persistente), estas políticas pueden marcar la diferencia para que tus herramientas no se caigan y, si lo hacen, se levanten solas sin intervención humana.

Alternativas antiguas y prácticas que conviene evitar

Apple dejó de lado Cron y LoginHooks como vías recomendadas para iniciar tareas; el camino oficial es launchd. También existieron StartupItems en versiones antiguas (carpetas en Librería del sistema y global), pero hoy no deben usarse para nuevas implementaciones.

Editar a mano los árboles del sistema (/System/Library/LaunchDaemons) puede terminar en un Mac que no arranca. No te la juegues: si necesitas arrancar muy temprano, utiliza /Library/LaunchDaemons con la configuración y permisos correctos, y deja los componentes del sistema en paz.

Supervisión de rendimiento y resolución de problemas

Si notas el Mac lento, abre Monitor de Actividad y ordena por CPU. Normalmente launchd no aparece en cabeza; si está al 30-40% de manera sostenida, reinicia el sistema y comprueba de nuevo. Si persiste, lista servicios con launchctl list y elimina sospechosos.

Para auditar qué elementos se registran con el nuevo marco, sfltool dumpbtm es oro: captura su salida y guárdala en tu reporte de soporte. Entre pruebas, sfltool resetbtm te deja el terreno limpio; recuerda reiniciar para evitar estados intermedios.

Los logs son tus amigos: con log stream --debug --info --predicate "subsystem == 'com.apple.backgroundtaskmanagement' AND category == 'mcx'" obtendrás detalle fino de altas, bajas y cambios. Acompáñalo con Consola filtrando por esos mismos campos si prefieres interfaz gráfica.

Gestión a escala con MDM y buenas prácticas

En despliegues gestionados, crea un perfil XML que describa reglas de aprobación (por ID de paquete, prefijo, TeamID, etiqueta o prefijo de etiqueta). Así, cuando una app registre su helper, macOS lo aprobará automáticamente y el usuario verá una notificación controlada.

Prueba tus flujos estándar (instalación, actualización, desinstalación) y valida el resultado con Declarative Device Management en macOS 14+ (reporte de estado) y con las herramientas mencionadas. Recoge feedback de usuarios y proveedores para adaptar las apps al nuevo marco.

Documenta la política interna: qué se autoriza, bajo qué criterios, quién revisa, cómo se audita y qué hacer si un elemento empieza a consumir recursos. Con esta higiene, evitas sorpresas y mejoras la seguridad y la estabilidad de la flota.

Consejos de limpieza y control continuo

Si tras desinstalar algo el ítem reaparece al inicio, busca su .plist por nombre en /Library/LaunchAgents, /Library/LaunchDaemons y ~/Library/LaunchAgents. Elimina el archivo y descarga el servicio con launchctl remove usando su Label.

Para aumentar tu visibilidad, habilita esas Acciones de carpeta comentadas: cada vez que entre un .plist nuevo en rutas sensibles, recibirás un aviso y podrás intervenir al momento. Es una medida sencilla que te ahorra quebraderos de cabeza.

Ten presente que los agentes son por-usuario y los daemons son del sistema. En máquinas compartidas, quizá quieras preferir agentes en ~/Library/LaunchAgents para no afectar a otros perfiles, salvo que sea una tarea corporativa transversal.

Si automatizas que una app se mantenga siempre abierta, recuerda que puede bloquear apagado o reinicio al relanzarse cuando el sistema intenta cerrar. Antes de actualizar o reiniciar, desactiva el servicio con launchctl remove o descarga el .plist, y vuelve a activarlo después.

Por último, no olvides revisar periódicamente Ajustes del Sistema > General > Elementos de inicio y la sección de elementos en segundo plano. Es la manera más rápida de detectar «polizones» que se cuelan con instaladores descuidados.

Dominar LaunchAgents y LaunchDaemons te da control: sabes qué arranca, cuándo y por qué; puedes aprobar lo legítimo con perfiles, diagnosticar con sfltool y logs, y reforzar la seguridad gracias a la transparencia que aporta SMAppService en macOS 13+. Con unas pocas reglas claras (rutas correctas, permisos, etiquetas coherentes y buen uso de KeepAlive) tendrás servicios estables, usuarios informados y un sistema más predecible, sin necesidad de pelearte con métodos obsoletos.