LaunchAgents son básicamente las mismas que LaunchDaemons, excepto que:
LaunchAgents sólo se ejecuta una vez que el usuario inicia sesión, se ejecuta el proceso en el que ha Iniciado la sesión en el UID (IDENTIFICADOR de Usuario) con el registro de los privilegios de usuario. Proceso puede interactuar con el usuario que ha iniciado a través de la interfaz gráfica de usuario.
LaunchDaemons se ejecuta en tiempo de arranque, antes de que la interfaz gráfica de usuario está en marcha, durante la barra de progreso en la pantalla de inicio. Se ejecuta como root, no es necesario tener ningún usuario que ha iniciado sesión, se ejecutan en el puro fondo (como servicios del sistema de windows, o Linux rc.d demonios), que no puede interactuar con cualquier usuario en la interfaz gráfica de usuario. [Esto es, básicamente, de los servicios del sistema, pero usted puede tener su propio servicio] (personalmente tengo un launchDaemon para descargar y actualizar mi archivo /etc/hosts el bloqueo de algunas URLs maliciosas, es un bash script que he creado como un servicio)
/Library/LaunchAgents/ - (Para todos los usuarios) [de la carga después de cualquier usuario inicia sesión en]
~/Library/LaunchAgents/ - (para un usuario ESPECÍFICO) [carga después de que él/ella entra]
--
Para cargar significa "ejecutar el servicio", se carga en memoria. Pero no se puede ejecutar exactamente en el tiempo de carga, si el interno plist ajuste establece, por ejemplo, un temporizador para ejecutar, después de X horas.
Por ejemplo:
Puedo crear mi costumbre demonio /Library/LaunchDaemons/local.updateHosts.plist
Voy a cargarlo:
sudo launchctl load /Library/LaunchDaemons/local.updateHosts.plist
"Carga" debe apuntar a la ruta/al/archivo.plist
**usted puede tener a kickstart después de la carga, de esta manera va a ser ejecutado, acabado, y espere a que el siguiente tiempo de ejecución (si se trata de un tiempo de servicio como la mía)*
Desde que está en LaunchDaemon, es un servicio del sistema.
[una breve pausa aquí sobre launchctl]
Porque para continuar necesitamos entender el MacOS proceso de ejecución de arquitectura:
MacOS Levanta dominios, sesiones de trabajo y espacios de nombres
Además BSD proceso de contextos [ UID ], MacOS tiene el Mach proceso de inicio de contextos, llamados espacios de nombres.
Un espacio de nombres es como un "lugar" o de agrupación, donde varios se ejecuta el proceso.
Bootstrap espacios de nombres están organizados jerárquicamente. Hay un Sistema de espacio de nombres global, a continuación tenemos una de cada usuario espacio de nombres (sin GUI), y debajo de ella tenemos una por sesión GUI espacio de nombres [creado por el WindowServer cuando el usuario se conecta a través de GUI] .
Jerárquicamente, cada nivel inferior pueden acceder a todos sus superiores niveles de espacio de nombres de servicios (sus padres de servicios de procesos)
----
System_Namespace
Per-User_Namespace
Per-Session_Namespace(GUI WindowServer)
----
Técnicamente la interfaz gráfica de usuario por sesión de espacio de nombres es
se llama 'Aqua' de la Sesión por parte de Apple de la API de google docs.
La jerarquía de arriba muestra el Sistema de Dominio, el Dominio de Usuario y la Sesión de Dominio (que pertenece el usuario, cada usuario tiene su propio)
Una vista ampliada con 2 usuarios registrados es el siguiente:
`
// System_Namespace [System]
// |
// ------ PerUSER_Namespace [Background] [user 501]
// | |
// | ----- PerSESSION_Namespace [Aqua] (MacOS GUI WindowServer) [user 501]
// |
// |
// ------ PerUSER_Namespace [Background] [user 502]
// |
// ----- PerSESSION_Namespace [Aqua] (MacOS GUI WindowServer) [user 502]
// ----
//
`
Esta es exactamente la root de la arquitectura de seguridad de los MacOS, es el llamado Mach Capa, que funciona en conjunto con el BSD (Capa que se encarga de usuario permisos de archivo y otros linux/bsd/unix permisos).
MacOS tiene 2 diferentes mecanismos de seguridad integrados y trabajando juntos: el Unix + el Mach mecanismos de seguridad.
Continuando unos launchctl, cuando estás a punto de crear un demonio/servicio que usted tiene que elegir dónde se va a ejecutar, que el dominio, y en qué contexto.
En primer lugar, permite imprimir el dominio del sistema de servicios, esto mostrará una lista de todos los launchdaemons, cargados o no, habilitados y deshabilitados uno.
sudo launchctl print system/
Ahora, vamos a imprimir el usuario de los servicios de dominio: (teniendo en cuenta userid 501, usted puede encontrar otros usuarios de números de identificación con el comando: id username
sudo launchctl print user/501
Nota: Catalina también acepta la sintaxis: sudo launchctl print user/admin <- nombre de usuario
También puede consultar un PID, y verificar en qué dominio y el espacio de nombres se está ejecutando:
sudo launchctl print pid/784 (considerando 784 es el PID del Buscador, por ejemplo)
> $ sudo launchctl print pid/758
com.apple.xpc.launchd.domain.pid.Finder.758 = {
type = process
handle = 758
active count = 91
on-demand count = 1
service count = 90
active service count = 2
activity ratio = 0.02
originator = /System/Library/CoreServices/Finder.app
creator = Finder.758
creator euid = 503
uniqueid = 758
external activation count = 0
security context = {
uid = 503
asid = 100008
}
bringup time = 20 ms
death port = 0x52a63
in-progress bootstraps = 0
pended requests = 0
pending requests = {
}
subdomains = {
}
pending attachments = {
}
task-special ports = {
0x3fc73 4 bootstrap com.apple.xpc.launchd.user.domain.503.100008.Aqua
0x15f03 9 access com.apple.taskgated
}
Bajo El Contexto De Seguridad:
com.apple.xpc.launchd.dominio.pid.Finder.758
com.apple.xpc.launchd.usuario.dominio.503.100008.Aqua
Medios:
- Buscador, que ha PID 758
- fue creado por launchd,
- bajo el dominio de usuario,
- para el usuario 503,
- que se está ejecutando una interfaz gráfica con el IDENTIFICADOR de sesión 100008.
Ahora usted puede elegir y dominio de control, los espacios de nombres de usuario y para su demonio.
bootout significa detener un servicio que se está ejecutando, por ejemplo:
sudo launchctl bootout system/com.apple.netbiosd
Esto detiene el netbios demonio.
__
Permite volver a ese servicio que hemos creado con este comando:
sudo launchctl load /Library/LaunchDaemons/local.updateHosts.plist
la carga es el único parámetro que se le pasa la ruta de acceso completa de la .plist archivo, todos los demás launchctl comandos funciona a través de la referencia de la jerarquía de dominio!
Para imprimir nuestro servicio es: sudo launchctl print system/local.updateHosts
no uses la extensión .plist, y la referencia es el sistema/proceso.nombre
El nombre del proceso es lo que se definen dentro de la .plist archivo bajo llave de la Etiqueta:
<key>Label</key>
<string>local.updateHosts</string>
<key>ProgramArguments</key>
<array>
El bootstrap parámetro para forzar la carga de su servicio, mientras que la elección de dominio o espacio de nombres que desea que se ejecute, por ejemplo:
sudo launchctl bootstrap user/503 /Library/LaunchDaemons/local.updateHosts.plist`
/Library/LaunchDaemons/local.updateHosts.plist: Service cannot load in requested session
El comando de arriba de error devuelto porque mi servicio .plist sólo permitir que mi servicio para que se ejecute como un servicio del sistema, de lo contrario hubiera sido iniciado por el usuario 503.
bootstrap permite iniciar cualquier servicio o XPC paquete de servicio bajo otros dominios de los espacios de nombres. Básicamente, usted elige un servicio Y un objetivo para que se ejecute.
Adicional sintaxes:
sudo launchctl sistema de arranque/local.updateHosts
sudo launchctl sistema de parada/local.updateHosts
sudo launchctl unload sistema/local.updateHosts
sudo launchctl kickstart sistema/local.updateHosts
Si quieres ir a ultra-profundo sobre este tema, sugiero que este excelente documentación de Apple, es muy técnico y muy detallada:
https://developer.apple.com/library/archive/documentation/Darwin/Conceptual/KernelProgramming/contexts/contexts.html#//apple_ref/doc/uid/TP30000905-CH212-BEHJDFCA
