Archivo de la unidad Systemd Creación de un servicio
Con sus servicios, Systemd hace que todo sea más fácil, realmente más fácil. Tan pronto como desee algo que monitoree su aplicación y el control fácil de ella, Systemd es el camino a seguir, y eso es lo que voy a explicar aquí!
¿Dónde están los servicios Systemd?
Para agregar un nuevo servicio, bueno, debe responder a esta pregunta. Como siempre en Systemd, depende si el servicio es solo para su usuario o todo el sistema. Nos centraremos en cómo funciona Systemd para servicios de todo el sistema.
La ubicación exacta depende de por qué y de cómo se instaló el servicio. Si el servicio es instalado por un administrador de paquetes, generalmente estará en/usr/lib/systemd/sistema. Para el software que desarrolla o los que no admiten Systemd por sí solo, colocará el archivo de servicio en/usr/local/lib/systemd/system. Sin embargo, tenga en cuenta que algunas distribuciones no admiten esta carpeta en /usr /local. Finalmente, si desea configurar un servicio Systemd existente,/etc/Systemd/System es el camino a seguir.
Dentro de estas carpetas puede encontrar múltiples extensión de archivo como *.zócalo, *.objetivo o *.servicio. Obviamente nos vamos a centrar en el último. Systemd utiliza el nombre de archivo como el nombre del servicio al iniciarlo o detenerlo, etc. Por lo tanto, generalmente los nombres de archivo en el servicio solo contienen caracteres alfanuméricos junto con guiones y subrayos. Durante el desarrollo, recomiendo crearlo en sus documentos y luego copiarlo a la ubicación de Systemd cuando esté terminado, eso evitaría problemas si ahorra en el medio de la edición.
OK, así que cree su archivo de servicio en sus documentos. Ahora estamos listos para revisar cómo escribir este archivo.
[NOTA: Consulte el informe potencial de errores en la sección de comentarios de esta publicación de blog]
Descripción = Penguins Aplicación web HTTP Server (que se ejecuta en el puerto 8080)
Wantedby = Multi-user.objetivo
[Servicio]
Tipo = simple
Execstart =/usr/bin/python3/usr/local/bin/penguin-web-app/main.py
Reiniciar = siempre
El formato de archivo está de hecho cerca de INI. Sé que puede ser extraño dado que los archivos ini a menudo se encuentran en Windows, pero así es como funciona. El archivo de servicio se divide primero en 2 secciones: [unidad] y [servicio]. Cada sección configura un aspecto específico de Systemd: [unidad] contiene elementos compartidos por todos los archivos de la unidad Systemd, mientras que [el servicio] es solo para la configuración específica para configurar un nuevo servicio.
Entonces la sección está configurada con propiedades como Descripción = o ExecStart =. El valor se separa del nombre de la propiedad por el signo igual = sin ningún espacio.
Volvamos al archivo que se muestra arriba. Describe un servicio diseñado para ejecutar una aplicación web escrita en Python sobre Penguins. Systemd lo reiniciará cada vez que el proceso salga e inicie el servidor al inicio del servidor si lo habilita con el comando de habilitación de SystemCTL. Genial eh?
Pero tal vez eres tu próxima aplicación web no se trata de pingüinos - Y eso es una pena - Y no está escrito en Python. En este caso, querrá aprender más sobre las posibles configuraciones.
Propiedades de los servicios Systemd
Primero centrémonos sobre las propiedades en [Unidad]:
Descripción = se trata solo de dar una descripción clara de lo que está haciendo el servicio. Se muestra en la lista de servicios, registros de servicio, por lo que desea que sea descriptivo, pero debe permanecer en una línea y una oración.
Wantedby = permite decirle a Systemd: cuando se inicia esto, también me inicia. Generalmente pondrás el nombre de un objetivo. Ejemplos de objetivos comunes:
- multi usuario.objetivo: cuando el servidor está bien y está listo para ejecutar aplicaciones de línea de comandos
- gráfico.Objetivo: Cuando GNOME o KDE están listos
- red.objetivo: cuando el servidor está conectado correctamente a una red
Ok para el comienzo, estas propiedades de [unidad] son suficientes. Echemos un vistazo a [Servicio] ahora.
Type = ayuda systemd en cómo saber si un servicio se está ejecutando. Aquí hay tipos comunes:
- Simple es probablemente el más utilizado: Systemd considera el proceso que inicia como el que hace el servicio. Si el proceso se detiene, considera que el servicio también se detiene, etc.
- Se prefiere el bifurcación para las aplicaciones que se escribieron como un servidor pero sin la ayuda de un sistema de administración de servicios. Básicamente, espera que el proceso lanzado se bifurca y que Fork se considera el proceso final para el servicio. Para ser más preciso, también puede ayudar a Systemd con un archivo PID, donde la aplicación PID del proceso para rastrear es escrita por la aplicación lanzada.
Execstart = es probablemente el más importante para un servicio: precise qué aplicación iniciar al iniciar el servicio. Como puede ver en el servicio de pingüinos, he usado/usr/bin/python3 y no python3 de inmediato. Es porque la documentación de Systemd recomienda explícitamente usar rutas absolutas para evitar cualquier sorpresa.
Pero eso también es por otra razón. El sistema de gestión de otros servicios tiende a basarse en scripts de shell. Sin embargo, Systemd, por razón de rendimiento, no ejecuta un shell de forma predeterminada. Por lo tanto, no puede proporcionar directamente un comando shell en execstart =. Sin embargo, todavía puede usar un script de shell haciendo:
Execstart =/usr/bin/bash/usr/local/bin/lanzar-pinguin-server.mierda
No es tan duro? Tenga en cuenta que si necesita ejecutar algún proceso para indicar su servicio para detenerse limpiamente, Execstop = existe, así como ExecReload = para recargar los servicios.
Reiniciar = le permite decir explícitamente cuándo se debe reiniciar el servicio. Esta es una de las características importantes de Systemd: asegura que su servicio permanezca despierto todo el tiempo que desee, así que preste mucha atención a esta opción.
| Reiniciar = | Significado |
| siempre | Systemd seguirá reiniciándolo siempre que termine o se bloquee. Bueno, hasta que realice el nombre del servicio SystemCtl Stop.servicio. Es perfecto para servidores y servicios en línea, ya que prefiere pocos reinicios inútiles sobre tener que reiniciar manualmente el servicio sin ningún motivo. |
| en abnormal | Cuando el proceso de servicio se bloquea, reinicie el servicio. Sin embargo, si la aplicación sale limpiamente, no la reinicie. Es más útil para cron-wobs como servicios que necesitan hacer una tarea de manera confiable, pero no necesita ejecutar todo el tiempo. |
| en falsificación | Al igual que On-Abnormal, pero también reinicia el servicio cuando la aplicación sale de manera limpia pero con un código de salida no cero. Los códigos de salida no cerosos generalmente significa que ocurre un error. |
| No | Systemd no reiniciará el servicio automáticamente. Generalmente útil para obtener acceso a otras características de Systemd, como el registro sin la función de reinicio. |
WorkingDirectory = puede hacer cumplir un directorio de trabajo al lanzar su aplicación. El valor debe ser una ruta de directorio absoluta. El directorio de trabajo se usa cuando usa rutas relativas en el código de su aplicación. Para nuestro servicio de pingüinos, podría ser:
WorkingDirectory =/srv/penguin-web-app/
Entonces, la seguridad es importante, por lo que generalmente no desea lanzar su servicio con privilegios raíz. User = y group = le permite establecer el nombre del usuario o grupo o UID/GID en el que se iniciará su aplicación. Por ejemplo:
Usuario = Penguin-Web
Grupo = Penguin-Web
EnvironmentFile = es una opción poderosa. Las aplicaciones que se ejecutan como servicios a menudo necesitan archivos de configuración y entorno permiten establecer esa configuración de dos maneras:
- La aplicación puede leer directamente la variable de entorno.
- Pero también puede establecer diferentes argumentos de línea de comandos en su aplicación sin cambiar el archivo de servicio.
La sintaxis de este archivo es simple: escribe el nombre de la variable de entorno, el signo igual = y luego su valor. Luego coloca la ruta absoluta de su archivo de entorno en la propiedad de entorno.
Entonces, ejemplo:
EnvironmentFile =/etc/penguin-web-app/ambiente
Y el archivo/etc/penguin-web-app/entorno contiene:
Escuchar_port = 8080
Luego, nuestra aplicación web de Penguins tendrá acceso a la variable de entorno Listen_Port y escucha el puerto esperado.
Guarde y comience el servicio SystemD recién creado
Entonces, si siguió mi consejo, editó su archivo de servicio en su directorio de inicio. Una vez que esté satisfecho, copie ese archivo a/usr/local/lib/systemd/sistema, suponiendo que su distribución admite esa ruta. El nombre de archivo de su archivo de servicio será su nombre de servicio. Este nombre de archivo tiene que terminar con .servicio. Por ejemplo, para nuestro servidor Penguins, sería Penguin-Web-App.servicio.
Luego, debe decirle a SystemD que agregó un nuevo servicio, por lo que debe escribir este comando:
$ sudo SystemCtl-Daemon-Reload
Bien, ahora Systemd es consciente de su nuevo servicio, suponiendo que su archivo no contenga un error de sintaxis. Después de todo, es su primer archivo, por lo que es probable que cometa errores. Debe ejecutar este comando anterior en cada actualización de su archivo de servicio.
Ahora, es hora de comenzar el servicio:
$ sudo systemctl start penguin-web-app.servicio
Si falla con una unidad no encontrada por error como este:
$ sudo systemctl start penguin-web-app.servicio
No se pudo comenzar Penguin-Web-App.Servicio: Unidad no encontrada.
Significa que su distribución no admite el directorio o no ha nombrado correctamente su archivo de servicio. Asegúrese de verificar.
Si configura su servicio con WantedBy = y desea que su servicio comience automáticamente, debe habilitarlo, con este comando:
$ sudo systemctl habilitar penguin-web-app.servicio
Lo bueno de un servicio es que se ejecuta en segundo plano. El problema: cómo saber si se ejecuta correctamente y si se está ejecutando si se ejecuta en segundo plano? No se preocupe, el equipo de Systemd también pensó en eso y proporcionó un comando para ver si se ejecuta correctamente, ya que cuánto tiempo, etc.:
$ systemctl status penguin-web-app.servicio
Conclusión
Felicitaciones! Ahora puede administrar sus aplicaciones sin que se preocupe por reiniciarla manualmente cada vez. Ahora, le recomiendo que lea nuestro otro artículo sobre los registros de Systemd: Master JournalCtl: Comprender los registros de Systemd. Con eso, puede usar el poderoso sistema de registro en su nuevo servicio y crear servidores más confiables!