Los servidores Linux están diseñados para funcionar todo el tiempo; en lugar de iniciar programas importantes manualmente y dejarlos en un tmux sesión, debe agregarlos a systemd como un servicio que se iniciará automáticamente al arrancar y se reiniciará si surgen errores.
Trabajar con Systemd y servicios
Systemd almacena la configuración de los servicios en dos lugares. El primero es /lib/systemd/system/, donde encontrará la configuración de muchos servicios en su sistema. La mayoría de las instalaciones de software instalan servicios aquí. El segundo es /etc/systemd/system/, que anula el /lib/systemd directorio y se utiliza de forma general para colocar servicios creados por el usuario. Además hay /etc/systemd/users/, que ejecuta servicios para usuarios individuales que han iniciado sesión, como buscar correo.
Muchos de estos servicios no se ejecutan todo el tiempo como lo harían nginx o MySQL. Puede imprimir una lista de los servicios hoy en día en uso con:
service --status-all
Los servicios con un símbolo «+» se están ejecutando y los servicios con un símbolo «-» están hoy en día detenidos. Puede ver información más detallada con:
service status nginx
Dado que los servicios se ejecutan en segundo plano, no registran su salida en su consola, sino que registran la salida en el diario systemd. El comando «estado» mostrará las últimas líneas de este diario, pero puede leerlo de forma directa con:
journalctl -fn 50 -u nginx
Este comando imprime las 50 entradas de registro más recientes (-n) desde el servicio nginx (-u). Está configurado para imprimir todo y comenzar en la parte inferior, siguiendo las nuevas entradas de registro a medida que se crean (-f).
De todos modos, muchas aplicaciones seguirán escribiendo la mayoría de las cosas en sus registros de acceso o error, por lo tanto asegúrese de comprobarlos además. El diario realiza un seguimiento de las cosas registradas de forma directa en la consola, lo que puede ser útil para depurar sus propios servicios.
Configuración de servicio simple
Systemd se utiliza para muchas cosas en Linux; cada objeto que gestiona se denomina Unidad y tiene un “Archivo de Unidad” respectivo que establece lo que son. Estos pueden ser servicios simples como nginx o MySQL, pero además pueden ser cosas como puntos de montaje, dispositivos, sockets y muchas otras cosas ocultas, todo gestionado por systemd. Las unidades además pueden ser objetivos, utilizado para controlar cuándo se ejecutarán otros servicios (dicho de otra forma, después de que se inicialice la red).
A pesar de esto, para este caso de uso, probablemente solo desee configurar su aplicación como un servicio básico. Para hacer esto, tendrá que crear un nuevo archivo de unidad, que querrá colocar en /etc/systemd/system/ y nombre con un .service extensión:
touch /etc/systemd/system/myapp.service
Los archivos de unidad disponen algunas secciones diferentes, pero en general se verán así:
[Unit] Description=Example Service After=network.target StartLimitIntervalSec=0 [Service] Type=simple Restart=always RestartSec=1 User=serviceuser ExecStartPre= ExecStart=/path/to/executable [options] ExecStartPost ExecStop= ExecReload= [Install] WantedBy=multi-user.target
Primero, el [Unit] sección, que establece un montón de metadatos sobre la unidad. los After= La directiva se puede usar para retrasar la activación de la unidad hasta que se inicie otra unidad, como network, u otro servicio, como mysql.service Esto no hace que dependa mucho de ese servicio, aún cuando puede hacerlo con el Requires= o Wants= directivas. Esta sección además configura el número máximo de veces que la unidad intentará iniciarse antes de que systemd se rinda por completo; dado que probablemente desee que siga intentándolo, puede configurarlo en 0 para deshabilitar esta conducta.
El siguiente es el [Service] sección, específica para los archivos de la unidad de servicio. Aquí es donde configurará las alternativas de Exec. User ejecutará el servicio como un determinado usuario. Puede configurar esto en su cuenta de usuario personal, root o una cuenta de servicio personalizada. Solo asegúrese de que el usuario tenga suficientes permisos para hacer su trabajo.
Aquí hay algunas directivas diferentes para especificar los programas que se ejecutarán. ExecStartPre se ejecutará primero, lo que le permitirá realizar cualquier configuración necesaria antes de que el servicio se inicie verdaderamente. ExecStart es el ejecutable principal. ExecStartPost corre después, y ExecStop se ejecuta cuando el servicio se apaga. ExecReload es una directiva especial y se utiliza cuando llama a «recargar» en lugar de reiniciar. Esto le posibilita volver a cargar la configuración en tiempo de ejecución, siempre que su aplicación tenga la capacidad.
Por último, el [Install] sección, que establece algunos comportamientos más relacionados con la forma en que systemd maneja la unidad. Esto se utiliza más comúnmente para especificar el WantedBy= directiva, que se utiliza para decirle a systemd cuándo iniciar su servicio, y crea links simbólicos entre los objetivos y sus unidades dependientes. Si no está seguro de qué objetivo usar, multi-user.target ejecutará los servicios al inicio después de que casi todo esté cargado.
En general, la configuración es bastante sencillo y todo lo que verdaderamente debe hacer es poner su ejecutable como argumento en el [Service] sección. Una vez que se crea su servicio, tendrá que volver a cargar el demonio systemctl para actualizar con sus cambios:
sudo systemctl daemon-reload
Y habilítelo (que lo ejecutará en el arranque, según la configuración de la unidad):
sudo systemctl enable myapp
Y después inicie el servicio:
sudo service myapp start
El servicio ahora debería ejecutarse en segundo plano y puede verificar journalctl para ver su salida. Si sale, systemd lo iniciará automáticamente de nuevo, y debería ejecutarse en el inicio junto con los otros servicios en su sistema.
Si necesita reiniciar su servicio, puede utilizar:
sudo service myapp restart
Que ejecutará el ExecStop= directiva, apague la unidad y vuelva a encenderla.
