Systemd es un conjunto de demonios o daemons, herramientas, librerías y servicios diseñados para administrar y configurar de manera centralizada todos los servicios en sistemas operativos Linux. Systemd nos permite interactuar directamente con el núcleo o kernel del sistema operativo,

 

 

SysV ha sido desplazado de GNU/Linux y sustituido por systemd.

 

systemd es un sistema init y un administrador del sistema que se ha convertido en el nuevo estándar para las distribuciones Linux. Debido a su gran adopción, merece la pena familiarizarse con systemd, ya que hará que administrar servidores sea mucho más fácil. Conocer y utilizar las herramientas y daemons que componen systemd le ayudará a apreciar mejor la potencia, la flexibilidad y las capacidades que proporciona, o al menos a simplificar su trabajo.
 

Crea un servicio o daemon propio

Lo primero que debemos hacer es entrar en la ruta donde se encuentran todos los servicios de Systemd, en nuestro caso os vamos a poner los ejemplos haciendo uso de Debian, pero la ruta en los diferentes sistemas operativos es exactamente la misma, no debería haber ninguna diferencia.

La ruta donde debemos ir para ver todos y cada uno de los servicios es «/etc/systemd/system/», por lo tanto, si usamos el comando «cd» vamos a poder ir hasta esta ruta sin problemas:

Si hacemos un «ls» para listar todos los servicios, vamos a poder ver todos los que hay creados de forma predeterminada. Dependiendo de los programas que hayas instalado, tendremos unos servicios u otros.

[Unit]
Description=Daemon TTRSS Auto-Update Feeds
After=network.target mysql.service
[Service]
User=www-data
ExecStart=/var/www/html/rss/update_daemon2.php
[Install]
WantedBy=multi-user.target

Debemos tener en cuenta que este servicio se iniciará siempre con el sistema operativo, a no ser que decidas que no sea así.

A continuación, qué significa cada una de las partes del fichero de configuración anterior:

Opciones básicas

• Description: podemos introducir aquí el nombre y una descripción de lo que va a hacer nuestro daemon, en este caso podemos poner lo que nosotros queramos, es una descripción de cara al administrador de sistemas, para conocer qué hace el daemon sin necesidad de mirar más código.
• After: indicaremos si queremos que se cargue después de otros servicios o componentes del sistema. Esto es algo muy importante, porque si nuestro servicio requiere que otro servicio esté levantado, entonces tendremos que seguir una secuencia en concreto. También existe otra directiva llamada «Before» que hace lo contrario, indicando que nuestro servicio se ejecute antes que ese otro servicio que nosotros especificamos.
• User: el usuario del sistema operativo que ejecutará el daemon. También puede funcionar con Group. Esto es muy importante, porque dependiendo de los permisos que necesite el servicio, tendremos que ejecutarlo con root, nuestro usuario no privilegiado o cualquier otro usuario del sistema.
• ExecStart: debemos indicar la ruta absoluta (no funcionan relativas) al script o binario que queremos ejecutar para arrancar el servicio en cuestión.
• WantedBy: directivas de uso y otras dependencias.

Opciones completas:

• Description. Aquí puedes introducir la definición o descripción del servicio. Esta información es la que aparecerá en el log y en la salida del comando systemctl status. Es decir, que tiene que ser suficientemente descriptiva para ti.
• After. Esta directiva indica que nuestro servicio tiene que iniciarse después de que la red esté lista. En el caso de que tuvieramos que esperar a que estuvira listo MariaDB, la directiva sería tal como After=mysqld.service. También podemos encadenar varios servicios, separados por espacio, por ejemplo

After=syslog.target network.target sshd.service

• ExecStart. Aquí debe figurar la ruta al ejecutable, así como los parámetros necesarios para que arranque.
• Type. Permite configurar el inicio de nuestro servicio. Así tenemos,

1.  simple. El proceso empieza con ExecStart y es el principal proceso del servicio.
2. forking. En este caso se lanza un proceso hijo, que se convierte en el proceso principal.
3.  oneshot. El proceso termina antes de comenzar con las siguientes unidades.
4.  dbus. Las siguientes unidades empezarán cuando el proceso principal tegan el D-Bus.
5.  notify. En este caso depende de un mensaje de notificación enviado por sd_notify.
6.  idle. La ejecución del servicio se retraza hasta que todos los trabajos han terminado.

• Restart. Por defecto Systemd, no reinicia tu servicio en caso de que este caiga, por la razón que sea. Sin embargo, a ti lo que te interesa es que tu servicio siempre esté en funcionamiento. Para lograr esto, tienes que poner la directiva Restart=always. Otra opción es utilizar Restart=on-failure, en cuyo caso solo se reinicializará si el servicio se ha parado por fallo.
• RestartSec. Te permite definir el tiempo que debe transcurrir hasta que se intente poner de nuevo en marcha tu servicio. Por defecto, Systemd, trata de levantar el servicio, transcurrido 100 ms. Con esta directiva, tu puedes establecer el tiempo en segundos. Sin embargo, es interesante que dejes como mínimo un segundo para no forzar la máquina.
•  StartLimitBurst y StartLimitIntervalSec. Estos dos parámetros te permitirán definir cuantos intentos StartLimtBurs y en que intervalo StartLimitIntervalSec, vas a permitir para que se restablezca el servicio. Por defecto, Systemd permite 4 intentos en 10 segundos. Por supuesto estableciendo RestartSec=3 nunca se alcanzarán estos valores.
•   StartLimitIntervalSec=0, obligará a Systemd a reiniciar el servicio tantas veces como sea necesario.
•  WantedBy. Esto equivale al runlevel. Establece el objetivo (Target) u objetivos bajo los que el servicio debería ser iniciado.

Objetivos o Targets

Los objetivos existentes los puedes ver en la siguiente tabla,

Runlevel     Objetivo     Descripción
0     poweroff.target     Apagado del sistema
1     rescue.target     Shell de rescate
2     multi-user.target     Sistema no gráfico
3     multi-user.target     Sistema no gráfico
4     multi-user.target     Sistema no gráfico
5     multi-user.target     Sistema gráfico
6     reboot.target     Apagado y reinicio

Para conocer cual es el objetivo definido por defecto, tienes que ejecutar la siguiente orden,

systemctl get-default

Gestionar servicios en tu distribución GNU/Linux

¿Cómo saber el sistema que usa mi distro? Pues, puedes saberlo buscando estas rutas, y si las tienes, tendrás ese sistema en tu distro:

• Para saber si tienes systemd: busca la ruta /usr/lib/systemd
• Para saber si tienes Upstart: busca esta otra ruta /usr/share/upstart
• Para saber si tienes SysV init: busca el path /etc/init.d
• Hay otros, aunque sea algo más raro, en esos casos particulares, puedes hacer algo similar si sospechas que no son los anteriores.

Otra forma de hacerlo incluso más sencilla, porque es la misma para todos, es buscar info en /proc sobre el PID=1, es decir, el primer proceso del que cuelgan el resto y que se corresponde precisamente con este demonio de inicio. Para ello, solo ejecuta el siguiente comando y te devolverá el nombre:

   

sudo stat /proc/1/exe

Ahora ya sabes qué sistema tienes, por tanto, vamos a los comandos que puedes usar para gestionar servicios:

• SysV init: /etc/init.d/[nombre_demonio_servicio] [acción]
• systemd: systemctl [acción] [nombre_demonio_servicio]
• Upstart: service [nombre_demonio_servicio] [acción]
• Otros: si usas otro sistema diferente, es mejor que mires el manual. Por ejemplo, algunos casos raros en Linux y otros Unix puede que usen la señal del proceso SIGHUP para restablecer un servicio: kill -HUP $(cat /var/run/[servicio-PID])

Tienes que sustituir [acción] por lo que necesitas hacer. Por ejemplo, si necesitas reiniciar, pues usa reset, si quieres parar usa stop, si quieres poner en marcha usa star, etc. Y sustituye [nombre_demonio_servicio] por el nombre del demonio del servicio que quieres poner en marcha. Por ejemplo:

systemctl reset httpd

Gestionar Servicios con SystemD

Habilitar servicio al iniciar PC

Ahora que ya hemos creado el servicio en el sistema operativo, antes de poder empezar a utilizarlo debemos habilitarlo con el comando «enable». Para poder hacer esto, simplemente tenemos que ejecutar el comando «systemctl enable» seguido del nombre del servicio que acabamos de crear. No es necesario ejecutar esto en la misma ruta donde se almacenan los archivos, en nuestro caso sería:

systemctl enable ttrssupdate.service

Por supuesto, nos pedirá la contraseña de superusuario del sistema para poder habilitarlo adecuadamente, para este tipo de tareas es fundamental tener permisos de superusuario, de lo contrario no podremos hacer nada.

Esto creará un enlace simbólico desde la copia del sistema del archivo de servicio (normalmente en /lib/systemd/system o /etc/systemd/system) en la ubicación del disco donde systemd busca los archivos de inicio automático (normalmente /etc/systemd/system/some_target.target.wants. Repasaremos qué es un destino más adelante en esta guía).

Ahora que ya hemos habilitado el servicio, lo tenemos que iniciar manualmente la primera vez. A partir de este momento siempre estará en ejecución, incluso cuando reiniciemos el sistema operativo, este servicio también arrancará automáticamente.

systemctl start ttrssupdate.service

En estos instantes, ya estará el servicio activo en nuestro sistema operativo. Aunque systemd puede ser bastante complicado si nos metemos en cosas avanzadas, crear un servicio no es demasiado complicado, tal y como habéis visto a lo largo de este tutorial. A continuación, os vamos a enseñar otros comandos muy útiles para administrar nuestro servicio recién creado:

• sudo systemctl reload: esta orden nos permite recargar todos los servicios de nuevo, muy útil por si modificamos varios de ellos, de esta forma, podremos hacerlo de forma global con todos.
• sudo systemctl stop ttrssupdate.service: este comando nos permite detener el servicio anteriormente iniciado, al detener el servicio podríamos hacer cambios que arrancado no se podrían hacer, por ejemplo, también para aplicar cambios tendremos que parar e iniciar el servicio.
• sudo systemctl restart ttrssupdate.service: nos permite reiniciar el servicio (es lo mismo que pararlo y arrancarlo, pero en un solo comando).
• journalctl -u ttrssupdate.service: nos permite ver el registro generado por el servicio en cuestión, por si hay algún error a la hora de ejecutarlo, o algún aviso que podría dar lugar a futuros problemas.
• sudo systemctl status ttrssupdate.service: nos permite ver la información de estado sobre el servicio en cuestión, este comando es fundamental para ver si está en funcionamiento o no.

 Para impedir que el servicio se inicie automáticamente, puede escribir:

sudo systemctl disable application.service

 

Esto eliminará el enlace simbólico que indicaba que el servicio debía iniciarse automáticamente.

Tenga en cuenta que habilitar el servicio no lo inicia en la sesión actual. Si desea iniciar el servicio y habilitarlo en el arranque, tendrá que emitir los comandos start y enable.

 

Administración de servicios

La finalidad principal de un sistema init es inicializar los componentes que deben iniciarse tras arrancar el kernel Linux (tradicionalmente conocidos como componentes “userland”). El sistema init también se utiliza para administrar servicios y daemons para el servidor en cualquier momento mientras se ejecuta el sistema. Teniendo eso en cuenta, comenzaremos con algunas operaciones básicas de administración de servicio.

En systemd, el destino de la mayoría de las acciones son “unidades”, que son recursos que systemd sabe cómo administrar. Las unidades se categorizan por el tipo de recurso al que representan y se definen con archivos conocidos como archivos de unidad. El tipo de cada unidad puede deducirse del sufijo al final del archivo.

Para las tareas de administración de servicio, la unidad de destino será unidades de servicio, que tienen archivos de unidad con un sufijo .service. Sin embargo, para la mayoría de los comandos de administración de servicio, puede dejar fuera el sufijo .service, ya que systemd es lo suficientemente inteligente para saber que probablemente quiere operar sobre un servicio cuando utiliza comandos de administración de servicio.

También hay métodos para comprobar los estados específicos. Por ejemplo, para comprobar si una unidad está activa actualmente (ejecutándose) puede usar el comando is-active:

    systemctl is-active application.service

Esto devolverá el estado actual de la unidad, que es normalmente activo o inactivo. El código de salida será “0” si está activo, lo que hace que el resultado sea más sencillo de analizar en las secuencias de comando shell.

Para ver si la unidad está habilitada, puede usar el comando is-enabled:

    systemctl is-enabled application.service

Esto indicará si el servicio está habilitado o deshabilitado y establecerá el código de salida a “0” o “1”, dependiendo de la respuesta a la pregunta del comando.

Una tercera comprobación es si la unidad está en estado fallido. Esto indica que hubo un problema al iniciar la unidad en cuestión.

systemctl is-failed application.service

Esto devolverá active si se está ejecutando adecuadamente o failed si se ha producido un error. Si la unidad se detuvo intencionadamente, puede devolver unknown o inactive. Un estado de salida de “0” indica que se produjo un error y un estado de salida de “1” indica cualquier otro estado.

Descripción general del estado del sistema

Los comandos hasta ahora han sido útiles para administrar servicios individuales, pero no son muy útiles para explorar el estado actual del sistema. Hay varios comandos systemctl que proporcionan esta información.

Cómo enumerar las unidades actuales

Para ver una lista de todas las unidades activas que systemd conoce, podemos usar el comando list-units:

    systemctl list-units

El resultado tiene las siguientes columnas:

• UNIT: El nombre de la unidad de systemd
• LOAD: Si la configuración de la unidad ha sido analizada por systemd. La configuración de las unidades cargadas se mantiene en la memoria.
• ACTIVE: Un estado resumido que indica si la unidad está activa. Esta es normalmente una forma bastante básica de saber si la unidad se ha iniciado correctamente o no.
•  SUB: Este es un estado de nivel inferior que indica información más detallada sobre la unidad. Esto a menudo varía por tipo de unidad, estado y el método real en el que se ejecuta la unidad.
•  DESCRIPTION: Una descripción textual breve de qué es y hace la unidad.

Listar todos los archivos de la unidad

El comando list-units solo muestra las unidades que systemd ha intentado analizar y cargar en la memoria. Ya que systemd solo leerá unidades que cree que necesita, esto no incluirá necesariamente todas las unidades disponibles en el sistema. Para ver todos los archivos de unidad disponibles en las rutas systemd, incluidos aquellos que systemd no haya intentado cargar, puede usar el comando list-unit-files:

 

systemctl list-unit-files

Mostrar dependencias

Para ver el árbol de dependencias de una unidad, puede usar el comando

systemctl list-dependencies sshd.service

Obtener y establecer el destino predeterminado

El proceso systemd tiene un destino predeterminado que utiliza cuando se inicia el sistema. Satisfacer la cascada de dependencias de ese destino individual llevará al sistema al estado deseado. Para encontrar el destino predeterminado de su sistema, escriba:

systemctl get-default

Output

multi-user.target

Si desea establecer un destino predeterminado diferente, puede usar set-default. Por ejemplo, si tiene un escritorio gráfico instalado y desea que el sistema se inicie a esto por defecto, puede cambiar el destino predeterminado:

sudo systemctl set-default graphical.target

Cómo enumerar los destinos disponibles

Puede obtener una lista de los destinos disponibles en su sistema escribiendo:

systemctl list-unit-files --type=target

A diferencia de runlevels, puede haber múltiples destinos activos a la vez. Un destino activo indica que systemd ha intentado iniciar todas las unidades relacionadas con el destino y no ha intentado desglosarlas de nuevo. Para ver todos los destinos activos, escriba:

systemctl list-units --type=target

Cómo usar atajos para eventos importantes

Existen destinos definidos para eventos importantes como apagar o reiniciar. Sin embargo, systemctl también tiene algunos atajos que añaden ciertas funciones adicionales.

Por ejemplo, para poner el sistema en el modo rescate (usuario único), puede usar simplemente el comando rescue en vez de isolate rescue.target,

 sudo systemctl rescue

Esto proporcionará la funcionalidad adicional de alertar a todos los usuarios con sesión iniciada sobre el evento.

Para detener el sistema, puede usar el comando halt:

sudo systemctl halt

Para iniciar un apagado completo, puede usar el comando poweroff:

sudo systemctl poweroff

Puede iniciar un reinicio con el comando reboot:

sudo systemctl reboot

Todos estos comandos alertan a los usuarios con sesión iniciada de que se va a producir el evento, algo que ejecutar o aislar el destino únicamente no hará. Observe que la mayoría de los equipos vincularán los comandos más cortos y convencionales para estas operaciones de forma que funcionen adecuadamente con systemd.

Por ejemplo, para reiniciar el sistema, normalmente puede escribir:

sudo reboot

Fuentes:

https://www.redeszone.net/tutoriales/servidores/administrar-servicios-linux-systemd/

https://www.linuxadictos.com/gestionar-servicios-en-tu-distribucion-gnu-linux.html 

https://www.digitalocean.com/community/tutorials/how-to-use-systemctl-to-manage-systemd-services-and-units-es