java - tutorial - systemd ventajas y desventajas

¿Qué beneficio obtengo de JSVC sobre simplemente usar systemd?

Question

La documentación de Tomcat describe el proceso de compilación e instalación de JSVC que se puede utilizar para ejecutar Tomcat como daemon. Según mi entendimiento, JSVC tiene dos beneficios:

1. Se inicia como root, lo que permite el uso de un puerto con privilegios (como 80 o 443).
2. Crea un "proceso de control" que supervisará un "proceso controlado" (el hilo principal de Java) y reiniciará el proceso en caso de falla.

He estado aprendiendo systemd , incluida la configuración de la unidad de servicio . Basado en mi entendimiento limitado, systemd puede realizar las mismas tareas que JSVC si configuro User=tomcat (usando el nombre de usuario deseado) y Restart=on-failure en mi archivo de configuración de tomcat.service .

Utilizando JSVC , esperaría que tomcat.service pareciera a esto:

[Unit]
Description=Apache Tomcat
After=network.target

[Service]
Environment=CATALINA_PID=/var/run/tomcat.pid
Environment=JAVA_HOME=/path/to/java
Environment=CATALINA_HOME=/opt/tomcat
...

ExecStart=/opt/tomcat/bin/jsvc /
    -Dcatalina.home=${CATALINA_HOME} /
    -user tomcat /
    -java-home ${JAVA_HOME} /
    -pidfile ${CATALINA_PID} /
    ...
    org.apache.catalina.startup.Bootstrap

ExecStop=/opt/tomcat/bin/jsvc /
    -pidfile ${CATALINA_PID} /
    ...
    -stop /
    org.apache.catalina.startup.Bootstrap

[Install]
WantedBy=multi-user.target

Usando systemd , esperaría que tomcat.service pareciera a esto:

[Unit]
Description=Apache Tomcat
After=network.target

[Service]
Type=forking  
PIDFile=/var/run/tomcat.pid
User=tomcat
Group=tomcat
Environment=JAVA_HOME=/path/to/java
Environment=CATALINA_HOME=/opt/tomcat
...

Restart=on-failure

ExecStart=/opt/tomcat/bin/startup.sh
ExecStop=/opt/tomcat/bin/shutdown.sh

[Install]
WantedBy=multi-user.target

Mi preferencia es usar simplemente systemd ya que está allí y tengo que (debería) usarlo de todos modos. Sin embargo, no estoy seguro de si me perderé algún beneficio de usar JSVC que estoy pasando por alto.

¿Qué se puede lograr con JSVC que no se puede lograr con systemd si quiero ejecutar Tomcat como daemon?

Además, si systemd puede realizar las mismas tareas que JSVC y JSVC, también me gustaría solicitar cualquier consejo de configuración que pueda ofrecer para lograr los mejores beneficios de JSVC utilizando solo systemd.

Answer 1

En este punto, usaría JSvc. Pero envuélvelo con un script de Systemd si tuviera que hacerlo.

1. Tenga en cuenta que JSvc es solo otro ejecutable. Entonces, un usuario regular del sistema puede configurar un servicio JSvc, por ejemplo. Es seguro decir que en la mayoría de las distribuciones, Systemd requiere la configuración de privilegios de administrador.

2. También escribí programas Java que usan JSvc y ProcRun.exe envolviendo una pequeña interfaz Java. Esto me permite utilizar el mismo código de servicio e incluso las pruebas de integración JUnit en los sistemas operativos Unix y Windows. Entonces, yo diría que JSvc y ProcRun.exe juntos facilitan el código de servicio multiplataforma.

3. JSvc tiene algunas opciones interesantes específicas de Java que pueden serle útiles. Por ejemplo, cómo iniciar la JVM (proceso o DLL), etc. Puedes escribir muchas de ellas en una secuencia de comandos de Systemd, pero sospecho que solo estarías reescribiendo JSvc en Bash en ese momento.

Entonces quizás no sea muy convincente para su ejemplo específico de Tomcat. Pero hay algunas ventajas al usar el pequeño contenedor de servicio JSvc sobre Systemd.

Answer 2

Debería usar jsvc si quiere ejecutar tomcat con privilegios que no sean root pero usando low port (<1024).

También se desactiva el puerto de apagado . Sin embargo, no se puede usar cuando se ejecuta Tomcat con los scripts de shell estándar, ya que evitará que shutdown.bat | .sh y catalina.bat | .sh dejen de hacerlo correctamente.

Answer 3

En general, la mayor parte de la funcionalidad proporcionada por jsvc es proporcionada por systemd, con la excepción de la apertura de puertos con privilegios (ver a continuación). Si es posible, es una muy buena idea cambiar al uso de la funcionalidad del sistema directamente, ya que las cosas se vuelven más simples y más eficientes.

El archivo de la unidad se ve generalmente bien, con la excepción de

ExecStart=/opt/tomcat/bin/startup.sh
ExecStop=/opt/tomcat/bin/shutdown.sh

Esta parte se ve como otra envoltura que puede ser reemplazada por una directo a java -jar ...

Apertura de zócalos privilegiados

En Systemd esto generalmente se realiza a través de la activación del socket. Systemd abre el socket y se lo da al daemon como un descriptor de archivo abierto (como stdin, stdout, stderr).

El daemon puede iniciarse como usuario sin privilegios y no descarta privilegios. El daemon tiene que soportar esto, y en lugar de abrir el socket por sí mismo, debería usar el que se le dio. Bajo Java esto se vuelve muy problemático por la falta de soporte en el estándar de Java.

AFAIK, tomcat no es compatible con la activación de socket, por lo que si desea utilizar un puerto con privilegios y ejecutar el daemon en un usuario sin privilegios, jsvc podría ser necesario.