Cómo generar un archivo de servicio systemd
- Rellena el nombre del servicio, una breve descripción, y el comando ExecStart (la ruta absoluta completa de lo que systemd debe ejecutar).
- Configura opcionalmente el directorio de trabajo, User/Group, el Type del servicio, y una política de reinicio con su retardo.
- Añade las variables de entorno y dependencias con otras unidades que necesites, elige “Start after” para el orden y un tipo de dependencia (suave/dura) de forma independiente, por cada unidad.
- Activa “Also generate a .timer unit” si quieres que este servicio se ejecute según una programación en vez de (o además de) al arrancar, y elige una programación de calendario o un retardo relativo al arranque.
- Copia o descarga el archivo
.service(y, si lo has activado,.timer), y sigue después los comandos de instalación que aparecen al final.
Por qué un generador visual de archivos de unidad systemd
Un archivo de unidad systemd es un formato pequeño y bien definido (secciones [Unit]/[Service]/[Install], cada una una lista plana de líneas Clave=Valor]) pero acertar cada detalle a mano es fácil de hacer mal de forma sutil: olvidar daemon-reload tras editar un archivo, confundir Wants= con Requires=, escribir un ExecStart= relativo que falla en silencio, o recurrir a la sintaxis de cron en OnCalendar= donde no encaja. Esta herramienta construye cada sección a partir de las convenciones reales y documentadas de systemd, e incluye solo lo que realmente has pedido, así obtienes un archivo de unidad completo y correctamente ordenado en vez de parchear fragmentos de varias entradas de blog escritas para versiones distintas de systemd.
Type=, explicado
Type= le dice a systemd cómo saber que tu servicio realmente ha terminado de arrancar, acertar mal aquí es una razón habitual por la que un servicio parece “arrancado” al instante sin estarlo realmente (o al revés, cuando systemd espera para siempre a un proceso que ya se bifurcó y se independizó). simple (el valor por defecto) trata el propio proceso de ExecStart como el servicio en ejecución. forking es para el patrón clásico de demonio Unix donde el proceso se bifurca y el proceso original termina, systemd necesita saberlo para no considerar el servicio “detenido” en el instante en que el proceso padre termina. oneshot es para un script pensado para ejecutarse una vez y salir (una tarea de configuración, un backup) en vez de quedarse ejecutándose. notify es para un proceso que le indica explícitamente a systemd que está listo vía sd_notify(), la opción más precisa, pero solo funciona si el programa realmente la soporta. dbus espera a que el servicio adquiera un nombre D-Bus concreto. idle se comporta como simple pero espera cortésmente a que terminen otras tareas de arranque primero, útil sobre todo para evitar salidas de consola entremezcladas durante el arranque.
Timers frente a cron
La unidad .timer que esta herramienta puede generar junto a tu .service es el propio mecanismo de programación de systemd, una sintaxis genuinamente distinta de cron, no un simple maquillaje. Un timer de tipo calendario usa OnCalendar=, la gramática propia de systemd para expresiones de hora de reloj (daily, weekly, o una expresión completa como Mon *-*-1..7 02:00:00), los presets de esta herramienta generan las palabras clave reales que documenta el propio systemd, y avisan si una expresión personalizada parece sintaxis cron de 5 campos en vez de una expresión OnCalendar= real. Un timer relativo al arranque usa OnBootSec=/OnUnitActiveSec= (un retardo fijo tras el arranque, o tras la última vez que se ejecutó el servicio) para tareas que dependen del tiempo transcurrido en vez de una hora de reloj concreta. Persistent=true (solo timers de calendario) hace que una ejecución programada perdida se dispare en cuanto la máquina vuelve a estar encendida, en vez de saltársela en silencio como hace cron.
Instálalo correctamente
Cada archivo generado viene con los comandos reales para usarlo de verdad: copia el archivo en /etc/systemd/system/, ejecuta sudo systemctl daemon-reload para que systemd lo detecte, y luego sudo systemctl enable --now <nombre> para activarlo en futuros arranques y arrancarlo de inmediato. Cuando se genera un timer, solo se activa el .timer, el .service se dispara POR el timer, así que activar ambos sería redundante (y, para un script pensado para ejecutarse solo según una programación, podría hacer que también se ejecutara una vez de inmediato al arrancar si el servicio lleva su propio objetivo [Install] separado).
Sin peticiones al servidor, sin cuenta
Cada campo se combina en texto de archivo de unidad usando JavaScript normal que se ejecuta en tu navegador, no se sube nada, no hace falta cuenta, y esta herramienta no tiene acceso a una instancia real de systemd para probar el arranque del resultado. Eso también la hace honesta sobre sus límites: es un generador de sintaxis, no un validador. Comprueba siempre systemctl status y journalctl -u <nombre> después de instalar una unidad nueva.
Usos habituales
- Convertir una app Node/Python/Go que de otro modo ejecutarías en una terminal (o con un frágil
nohup ... &) en un servicio real, persistente al reiniciar y que se reinicia solo si falla. - Construir la configuración de Nginx/Apache correspondiente al servicio que generas aquí, mira el Generador de Configuración Nginx & .htaccess.
- Contenerizar la misma app en vez de (o además de) ejecutarla como servicio nativo de systemd, mira el Generador de Dockerfile.
- Sustituir un trabajo de cron por un timer de systemd para una tarea de backup, rotación de logs, o renovación de certificados que se beneficie del registro en journald y de la recuperación con Persistent=, mira el Generador de Expresiones Cron si prefieres quedarte con la sintaxis clásica de cron para una programación sencilla.
- Configurar un servicio que debe esperar a la red, a una base de datos, o a otro servicio antes de arrancar, mira la pregunta sobre After=/Wants=/Requires= más arriba.
