Hace unos días comentaba el paso de System V a Upstart en RHEL y Centos 6. Hoy vamos a hablar sobre Solaris y el cambio introducido a partir de Solaris 9 para la gestión de servicios.

Antes de Solaris 9 los servicios se gestionaban como en la mayoría de sistemas Unix y Linux (legacy), teníamos scripts de arranque en /etc/init.d y se creaban enlaces simbólicos contra ellos en los distintos runlevels (directorios RC) para su arranque/parada. A partir de Solaris 9 se introdujo SMF (Service Management Facility) y se ha convertido en la manera por defecto de gestionar los servicios en Solaris 10.

Los beneficios de SMF sobre el método anterior son sustanciales. Entre ellos la posibilidad de mantener monitorizados los servicios para que en el momento que se produzca una caída levanten de forma instantánea, la gestión inteligente de arranque mediante la cual el servicio tiene unas dependencias y hasta que no estén activas el servicio no está disponible, el arranque en paralelo y de forma asíncrona, etc.

Los comandos básicos para gestion de servicios en SMF son svcs, svccfg y svcadm. Mediante svcs a secas podemos ver el estado de los servicios del sistema (incluidos los del sistema antiguo legacy), a través de distintos parámetros podemos filtrar únicamente los deshabilitados, etc:

# svcs
STATE          STIME    FMRI
legacy_run      9:04:48 lrc:/etc/rc2_d/S20sysetup
legacy_run      9:04:48 lrc:/etc/rc2_d/S47pppd
legacy_run      9:04:49 lrc:/etc/rc2_d/S72autoinstall
legacy_run      9:04:49 lrc:/etc/rc2_d/S73cachefs_daemon
legacy_run      9:04:49 lrc:/etc/rc2_d/S81dodatadm_udaplt
legacy_run      9:04:49 lrc:/etc/rc2_d/S89PRESERVE
disabled        9:02:34 svc:/platform/i86pc/acpihpd:default
online          9:01:28 svc:/system/svc/restarter:default
online          9:01:35 svc:/system/early-manifest-import:default
online          9:01:38 svc:/network/netcfg:default
online          9:01:39 svc:/network/datalink-management:default
online          9:01:39 svc:/network/socket-config:default
...
...

Básicamente vemos el estado del proceso, la última vez que el servicio cambió de estado y su FMRI (Fault Management Resource Identifier). El FMRI es el identificador del servicio. El FMRI se divide en tres partes separadas por “:”. La primera el esquema (svc o lrc según el tipo de servicio), la categoría en la que se encuentra (network, system…) y el nombre del servicio, y finalmente la instancia.

Podemos ver también con detalle el estado de un único servicio con el parámetro “-x” y sus dependencias con “-d”:

# svcs -x  svc:/system/cron:default
svc:/system/cron:default (clock daemon (cron))
 State: online since  1 de noviembre de 2011 09:02:51 WET
   See: cron(1M)
   See: crontab(1)
   See: /var/svc/log/system-cron:default.log
Impact: None.

# svcs -d svc:/system/cron:default
STATE          STIME    FMRI
online          9:02:35 svc:/milestone/name-services:default
online          9:02:49 svc:/system/filesystem/local:default

Podemos verificar rápidamente cómo SMF monitoriza activamente los servicios que están bajo su control, vamos a ver el estado del servicio cron, matarlo con una señal kill y verificar que al momento SMF lo ha levantado de nuevo:

# date
martes  1 de noviembre de 2011 09:46:24 WET
# svcs -v system/cron
STATE          NSTATE        STIME    CTID   FMRI
online         -              9:02:51     62 svc:/system/cron:default
# ps -ef | grep cron
    root   441     1   0 09:02:51 ?           0:00 /usr/sbin/cron
    root   841   687   0 09:46:33 pts/1       0:00 grep cron
# kill 441
# svcs -v system/cron
STATE          NSTATE        STIME    CTID   FMRI
online         -              9:46:38     96 svc:/system/cron:default

A través de svcs también podemos ver el estado de un servicio y diagnosticarlo cuando no es satisfactorio. Encontraremos los siguientes estados: online, offline, disabled, degraded, maintenance y legacy-run. Los cuatro primeros estados están claros, online, offline, deshabilitado y degradado. Cuando un servicio está en estado maintenance es debido a que hay algún problema con el servicio y no puede ser arrancado. Como requiere nuestra intervención se pone a nuestra disposición la ruta hacia el log del servicio para verificar el origen del problema. El estado legacy-run simplemente indica que se trata de un servicio legacy.

Mediante svcadm podemos gestionar el estado de cada uno de los servicios, con los parámetros “enable”, “disable”, “refresh”, “clear”, “mark” y “restart”. Aparte de los obvios, conviene comentar que “refresh” sirve para leer de nuevo los ficheros de configuración del servicio por si se ha realizado algún cambio, “clear” sirve para resetear el servicio si se encuentra en estado de mantenimiento y “mark” para marcar un servicio como degradado, mantenimiento, etc.

Para que veáis un ejemplo de fichero xml básico para un servicio aquí tenéis uno para la gestión de Oracle iPlanet webserver 7 que instalamos hace unos días. Básicamente hemos establecido como dependencias los servicios de red, los sistemas de ficheros locales y el arranque bajo el milestone multi-user (lo que viene siendo el runlevel 3 en legacy). Después establecemos los tres comandos para el arranque, parada y reinicio del servicio:

<?xml version='1.0'?>

<!DOCTYPE service_bundle SYSTEM '/usr/share/lib/xml/dtd/service_bundle.dtd.1'>

<service_bundle type='manifest' name='webserver7'>

<service name='network/webserver7' type='service' version='0'>
<create_default_instance enabled='true'/>
<single_instance/>
<dependency name='fs' grouping='require_all' restart_on='none' type='service'>
<service_fmri value='svc:/system/filesystem/local'/>
</dependency>
<dependency name='net' grouping='require_all' restart_on='none' type='service'>
<service_fmri value='svc:/network/physical'/>
</dependency>
<dependent name='webserver7_multi-user' restart_on='none' grouping='optional_all'>
<service_fmri value='svc:/milestone/multi-user'/>
</dependent>
<exec_method name='start' type='method' exec='su www -c "/opt/webserver7/bin/webserver7 start"' timeout_seconds='60'>
<method_context/>
</exec_method>
<exec_method name='stop' type='method' exec='su www -c "/opt/webserver7/bin/webserver7 stop"' timeout_seconds='60'>
<method_context/>
</exec_method>
<exec_method name='restart' type='method' exec='su www -c "/opt/webserver7/bin/webserver7 restart"' timeout_seconds='60'>
<method_context/>
</exec_method>
</service>

</service_bundle>

Para importar un servicio creado de este modo ejecutamos el siguiente comando:

# svccfg import webserver7.xml

Como siempre os recomiendo revisar las páginas man de todos estos comandos para recibir información detallada sobre cada uno de ellos, esto es una pequeña introducción que podría extenderse mucho más si entráramos en detalle de cada una de las características y posibilidades de SMF. Ahí van unas cuantas referencias para aprender más sobre Service Management Facility:

• Using Solaris SMF (O’Reilly)
• Universidad de Princeton, Service Management Facility
• OpenSolaris SMF FAQ

Normalmente para arrancar, parar y reiniciar servicios de Windows Server accedemos a Services, ya sea ejecutando services.msc desde Inicio > Ejecutar o desde Inicio > Panel de Control > Herramientas administrativas > Servicios. Otra forma, a veces más rápida es hacerlo directamente desde la línea de comandos (CMD) de windows. Para ello abrimos una ventana de cmd desde Inicio > Ejecutar > cmd.

Iniciar un servicio

Desde la línea de comandos ejecutamos:

net start servicio

Por ejemplo, para iniciar el servicio de correo mailenable sería:

net start mailenable

Parar un servicio

Desde la línea de comandos ejecutamos:

net stop servicio

Por ejemplo, para parar el servicio de correo mailenable sería:

net stop mailenable

Pausar un servicio

Desde la línea de comandos ejecutamos:

net pause servicio

Por ejemplo, para pausar el servicio de correo mailenable sería:

net pause mailenable

Reanudar un servicio

Desde la línea de comandos ejecutamos:

net continue servicio

Por ejemplo, para reanudar el servicio de correo mailenable sería:

net continue mailenable

Creo que todos los administradores de sistemas coincidimos en que un buen sysadmin es aquel que es capaz de conseguir que los sistemas se autogestionen en la mayor parte de lo posible. Esto implica, además de disponer de un buen sistema de monitorización tipo Big Brother, Nagios o Cacti, disponer de herramientas para que cuando un servicio o aplicación falle y se pare, automáticamente intenten reiniciarla sin necesidad del administrador.

Monit es una herramienta muy sencilla de instalar y configurar que se encargará de hacer esta tarea por nosotros. Monit permite monitorizar y gestionar procesos, ficheros, directorios y sistemas de ficheros.

Su instalación es realmente sencilla, podéis utilizar gestores de descargas como YUM o APT o compilarlo desde el código fuente (no tiene ningún misterio). Descarga aquí.

En CentOS o RHEL por ejemplo:

# yum install monit

Una vez instalado, simplemente tenéis que personalizar la configuración, encontraréis el fichero en la ruta /etc/monit.conf. Cada sección o directiva está perfectamente explicada, no obstante las más importantes:

set daemon  60             # check services at 2-minute intervals
     with start delay 240  # optional: delay the first check by 4-minutes (by
#                          # default Monit check immediately after Monit start)

set daemon indica que levantemos monit como demonio, a continuación le especificamos el intervalo de tiempo para el chequeo de servicios, también indicamos un retardo de 4 minutos para que no los chequee nada más arrancar.

 set mailserver localhost               # primary mailserver
set alert xxx@xxx.com/pre>

Con set mailserver indicaremos el servidor de correo a utilizar para el envío de alertas. Set alert especificará la cuenta de correo a la que enviar los avisos.

Ya pasamos a la configuración de servicios y lo que vamos a monitorizar. En primera instancia podemos indicar que nos envíe correos cuando el sistema alcance una determinada carga o uso de CPU, memoria, etc. Descomentar y personalizar según requerimientos:

#  check system myhost.mydomain.tld
#    if loadavg (1min) > 4 then alert
#    if loadavg (5min) > 2 then alert
#    if memory usage > 75% then alert
#    if swap usage > 25% then alert
#    if cpu usage (user) > 70% then alert
#    if cpu usage (system) > 30% then alert
#    if cpu usage (wait) > 20% then alert

También podemos monitorizar cambios en ficheros, permisos, checksum, usuarios y grupos, etc

## Check if a file exists, checksum, permissions, uid and gid. In addition
## to alert recipients in the global section, customized alert can be sent to
## additional recipients by specifying a local alert handler. The service may
## be grouped using the GROUP option. More than one group can be specified by
## repeating the 'group name' statement.
#
#  check file apache_bin with path /usr/local/apache/bin/httpd
#    if failed checksum and
#       expect the sum 8f7f419955cefa0b33a2ba316cba3659 then unmonitor
#    if failed permission 755 then unmonitor
#    if failed uid root then unmonitor
#    if failed gid root then unmonitor
#    alert security@foo.bar on {
#           checksum, permission, uid, gid, unmonitor
#        } with the mail-format { subject: Alarm! }
#    group server

En la parte de servicios podemos configurar servicios como Apache, Exim, FTP, MySQL, etc para que cuando haya un problema y se paren Monit los levante automáticamente, a continuación os dejo el ejemplo para Apache (rutas y demás pueden diferir según la instalación):

  check process apache with pidfile /usr/local/apache/logs/httpd.pid
    start program = "/etc/init.d/httpd start" with timeout 60 seconds
    stop program  = "/etc/init.d/httpd stop"
    if cpu > 60% for 2 cycles then alert
    if cpu > 80% for 5 cycles then restart
    if totalmem > 200.0 MB for 5 cycles then restart
    if children > 250 then restart
    if loadavg(5min) greater than 10 for 8 cycles then stop
    if failed host rm-rf.es port 80 protocol http
       and request "/index.phpsy"
       then restart
    if failed port 443 type tcpssl protocol http
       with timeout 15 seconds
       then restart
    if 3 restarts within 5 cycles then timeout
    #depends on apachectl
    group server

Como véis monitoriza el PID de apache y si no lo encuentra lo reinicia. También monitoriza el uso de CPU y memoria y si es muy elevado en X ciclos de comprobación lo reinicia o avisa al administrador, lo mismo para el SSL, etc.

En la ayuda de Monit encontraréis información sobre como añadir más servicios, aunque simplemente es coger el de apache como base y modificar parámetros. Otro ejemplo para MySQL:

check process mysql with pidfile /var/lib/mysql/mysql.pid
   group database
   start program = "/etc/init.d/mysql start"
   stop program = "/etc/init.d/mysql stop"
   if failed host 127.0.0.1 port 3306 then restart
   if 5 restarts within 5 cycles then timeout

Una vez que tengamos todo configurado, solo queda iniciar el servicio y comprobar su funcionamiento, por ejemplo tirando uno de los servicios monitorizados.

# /etc/init.d/monit start
Starting monit: Starting monit daemon
Monit start delay set -- pause for 240s
                                                           [  OK  ]

Tener Monit instalado es un buen ejemplo de monitorización proactiva en vuestros servidores. Os sirva para evitar tener que levantaros alguna que otra madrugada a levantar un servicio.

Lo primero que debemos saber es como encontrar todos los servicios configurados en el sistema, para ello:

Windows en español:

Inicio:> Ejecutar:> services.msc

Windows en inglés:

Start:> Run:> services.msc

Aparecerá una ventana como la de la imagen, en la cual podréis ver el listado de servicios del sistema, algunos iniciados, otros parados/deshabilitados, etc. Pinchando en cada uno de ellos con el botón derecho y después en “propiedades”.

Bien, aquí podéis revisar que servicios creéis necesarios y cuales no, pudiendo parar un proceso o deshabilitarlo para que no arranque en el inicio del sistema operativo.

Por otro lado, si lo que queremos es eliminar el servicio debemos hacerlo desde la línea de comandos de Windows:

Windows en español:

Inicio:> Ejecutar:> cmd

Windows en inglés:

Start:> Run:> cmd

Una vez en la ventana de línea de comandos, para eliminar un servicio:

sc delete nombre_del_servicio