Vamos a ver ahora cómo cargar un script para que se ejecute al inicio de un sistema GNU/Linux que utilice systemd como gestor de servicios. Es un ejemplo básico, luego ampliaremos con otros modificadores.

---

Para los que venimos del viejo y querido SysVInit, todo se reducía a crear un archivo en /etc/init.d/ con una determinada estructura, y activarlo.

Ahora, con systemd la cosa parece que se complica un poco, pero en realidad no tanto, y hasta resulta un poco más ordenado que el viejo sistema.

El script / binario / ejecutable

En este ejemplo vamos a suponer que necesitamos ejecutar un script que hemos colocado en /usr/local/bin/miscript.sh (nombre genérico)… por supuesto cada uno podrá adaptarlo a sus necesidades.

Cualquier archivo ejecutable, ya sea script o binario, vamos a poder cargarlo en nuestro sistema al momento de iniciar el sistema operativo.

Cable aclarar que se ejecutará al iniciar el sistema operativo, no el escritorio del usuario, por lo que si tienen la idea de arrancar Rambox o Firefox, o Pidgin al iniciar su sesión, este tutorial no les va ayudar! Para ello hay que cargar el ejecutable de la aplicación entre los iniciados automáticamente con la sesión de escritorio. Esto depende del entorno de escritorio que usen, pero en general está en el menú configuración -> Aplicaciones de Inicio, o Aplicaciones de sesión, o similar.

Por supuesto, el script o binario deberá tener permisos de ejecución, y para ellos podemos correr un comando similar a este:

sudo chmod +x /usr/local/bin/miscript.sh

Unidad de servicio systemd

Luego tenemos que crear una unidad de servicio systemd (systemd serivce unit).

Vamos a verlo funcionando con un ejemplo súper sencillo. La unidad de servicio es un archivo de texto común, en mi caso escribí el archivo /etc/systemd/system/miscript.service:

[Unit]
Description=Mi script automatico
After=network.target

[Service]
ExecStart=/usr/local/bin/miscript.sh
Type=oneshot
RemainAfterExit=true

[Install]
WantedBy=default.target

Donde:

• Description: información descriptiva que es mostrada en el log de journal de systemd cuando ejecutamos «systemctl status servicio.service«
• After: indica el servicio luego del cual correrá nuestro script. Supongamos que el script debe realizar algunas operaciones de red… sería lógico ejecutarlo luego de que se haya corrido network.service, cierto?
  Se pueden agregar otros servicios separándolos por un espacio en blanco.
• ExecStart: permite especificar la ruta completa al script que vamos a ejecutar, el nuestro.
• Type: forking en este caso es utilizado por daemons o residentes para que realicen una clonación de la llamada al sistema. El proceso principal del servicio es creado con un pid especificado en el archivo de pid escrito a continuación.
• WantedBy: especifica dentro de qué «target» de systemd debe ser instalado. Dejémoslo en default.target.

Sacando las opciones de Type, PIDFile y Description, esto es lo mínimo indispensable para poder ejecutar un script en systemd, las líneas mínimas para un service unit.

¿Que queremos más configuraciones y adaptaciones para nuestro entorno? Nada mejor que acercarse por la mesa de ayuda:

man systemd.service

Luego debemos darle permisos al nuevo archivo .service:

chmod 0644 /etc/systemd/system/miscript.service

Por cierto, luego de crear nuestra unidad de servicio, o de modificarla en el futuro, siempre debemos ejecutar el comando:

systemctl daemon-reload

Habilitando y ejecutando

Con estos pasos listos, ahora podremos habilitar el servicio con:

systemctl enable miscript.service

Y ejecutarlo con:

systemctl start miscript.service

Para otros comandos les recomiendo visitar SystemD vs SysVinit: algunos comandos.

Al estar habilitado / enabled, y al haberlo «instalado» en el target por defecto (default.target en la última línea del ejemplo), podremos ver su enlace simbólico en /etc/systemd/system/default.target.wants/

diego@cryptos:~/$ ls -l /etc/systemd/system/default.target.wants/
total 0
lrwxrwxrwx 1 root root 36 Mar 18 21:12 miscript.service -> /etc/systemd/system/miscript.service

Y por supuesto, si ejecutamos:

systemctl disable miscript.service

Estaremos eliminando dicho enlace simbólico.

Esperamos les resulte interesante y útil!

A futuro ampliaremos esta información con otros parámetros que pueden ser de interés para iniciar y detener servicios residentes del segundo plano.

Hasta la próxima!