Procesos
Ejecutar todos los servicios en su propio proceso, en lugar de tener varios servicios compartiendo proceso siempre que sea posible, es desperdiciar los recursos del sistema. Sin embargo, compartir el proceso significa que cualquiera de ellos que falle causará que el proceso se detenga, o sea, se pararán todos los servicios que lo comparten.
Algunos de los servicios integrados en Windows Server 2003 corren bajo su propio proceso; sin embargo la mayoría usan un proceso compartido con otros servicios.
Los servicios relacionados con la seguridad, como el servicio SAM (Security Accounts Manager), Netlogon y IPSec comparten el proceso Lsass.exe.
También existe un proceso genérico denominado Svchost, o la aplicación Svchost.exe(ruta_de_sistemaWindowsSystem32), que contiene múltiples servicios.
Proceso genérico
El proceso Svchost contiene múltiples servicios y varias instancias del proceso pueden estar ejecutándose al mismo tiempo bajo contextos de seguridad diferentes. Algunos de los servicios que se ejecutan dentro de este proceso son: Teléfono, RPC, Administrador de conexiones de escritorio remoto.
Windows Server 2003 implementa servicios que se ejecutan en Svchost como una DLL y especifica la ubicación de la DLL de un servicio en el valor del registro ImagePath (que tiene la forma ruta_de_sistemaSystem32svchost.exe -k nombre de la instancia) en la subclave correspondiente al servicio. Cada subclave del registro del servicio debe tener una entrada llamada ServiceDll en los parámetros de la subclave que apunte a la DLL del servicio. Todos los servicios que comparten un proceso Svchost común especifican el mismo parámetro (-k nombre de la instancia).
Normalmente, cada instancia de svchost que se ejecuta en Windows Server 2003 corresponde a una cuenta distinta. Hay un par de excepciones, como RPC por ejemplo, que se ejecuta con su propia instancia de LocalSystem por seguridad.
Cuando SCM encuentra el primer servicio que tiene un ImagePath de svchost.exe -k nombre de la instancia durante el inicio de servicio, crea una nueva entrada en la base de datos para la instancia de svchost e inicia el proceso como está configurado.
El nuevo svchost toma el parámetro y busca la subclave del registro que tiene el mismo nombre que el parámetro en HKLMSOFTWAREMicrosoftWindowsNTCurrentVersionSvcHost. Svchost lee el contenido de la subclave, interpretándolo como una lista de nombres de servicio y notifica al SCM que los aloje en cuanto Svchost los registre en SCM.
Cuando SCM encuentra un proceso Svchost durante el inicio de un servicio cuyo valor de imagePath coincide con una de las entradas que SCM ya tiene en su base de datos, no inicia un segundo proceso y en su lugar envía un comando de inicio para el servicio que el proceso svchost ya tiene iniciado para ese imagepath. El proceso existente lee el valor de ServiceDll en la subclave del servicio y carga la Dll dentro de su proceso para arrancar el servicio.
En general, la razón de compartir proceso los servicios es la disminución del uso de memoria y hilo, que se incrementan dramáticamente cuando vamos añadiendo procesos al sistema. Las distintas instancias de svchost en nuestro equipo, en su mayor parte, se ejecutan con diferentes cuentas, y cada una de ellas alberga los servicios que se ejecutan en una cuenta particular. Mediante la herramienta Tasklist.exe y el parámetro /svc, podemos ver la lista de cuentas por nombre para cada instancia de Svchost.
Grupos
Muchos servicios no trabajarán correctamente a menos que otros componentes del sistema no estén ya en ejecución. Cuando se inicia un equipo, éste sigue un algoritmo que dicta el orden en que los servicios se inician. En Windows, los servicios del sistema se dividen en un conjunto de grupos predefinidos. Asignar un servicio a un grupo no tiene otro efecto que afinar su inicio con respecto a otros servicios que pertenecen a grupos diferentes.
SCM construye su base de datos interna de servicios y lee y almacena el contenido de la lista de entradas en la subclave HKLMSYSTEMCurrentControlSetControlServiceGroupOrder, un valor de cadena que lista los nombres y su orden de los grupos de servicio especificados. Una subclave del registro del servicio contiene una entrada de grupo opcional para ser usado si el servicio o controlador de dispositivo necesita controlar su orden de inicio con respecto a los servicios dentro de otros grupos.
SCM lee el valor de la entrada Grupo del servicio para determinar si es un miembro de un grupo y lo asocia con la entrada del grupo en la subclave ServiceGroupOrden mencionada antes. SCM también lee y graba en la base de datos el grupo y las dependencias del servicio consultando las entradas DependOnGroup y DependOnService.
Desde la introducción del Plug&Play en Windows 2000, el mecanismo de orden de grupo de servicio se ha convertido en menos significante. En Windows Server 2003, Plug&Play es el responsable de la carga de los servicios y los controladores del kernel. Plug&Play administra la carga de controladores en modo-kernel según la presencia de sus dispositivos asociados.
SCM casi nunca está complicado con la carga de un controlador. Lo más interesante del uso que nos queda del mecanismo de orden de grupo de servicios en modo kernel es para file system filter drivers.
La opción auto-start para controladores en modo-kernel está desfasada. Aún cuando un controlador se marca como AUTO_START, en cuanto inicia la primera vez, recibirá un root-enumerated devnode registrado en su nombre, y en todos los siguientes inicios éste devnode hará al controlador ser cargado por Plug&Play durante la fase de arranque del sistema, antes de iniciarse SCM.
La opción demand-start está recomendada para casi todos los controladores Plug&Play. Demand-start ya no significa «cuando SCM es requerido para iniciar el controlador» (en respuesta a un comando NET por ejemplo) como en versiones de Windows anteriores. Ahora significa cuando Plug&Play lo «solicita» debido al descubrimiento de dispositivos asociados con el controlador.
Dependencias
Además de notificar al SCM que un servicio es parte de un orden de carga de grupo particular, se le puede decir que este servicio requiere otros servicios en ejecución antes de poder ejecutarse él mismo.
Hay dos tipos de dependencias:
- El servicio actual depende de otro para iniciar. Si el servicio X es antecedente al Y, el X debe estar en ejecución antes de ejecutar el servicio Y.
- Otros servicios dependen del servicio actual para iniciar. Si el servicio X es dependiente del Y, el Y debe estar en ejecución antes de iniciar el servicio X.