bash - programacion - spawn expect linux

¿Para qué sirve el uso de exec en los scripts de punto de entrada de docker?

Question

Por ejemplo en la imagen oficial de redis:

https://github.com/docker-library/redis/blob/master/2.8/docker-entrypoint.sh

#!/bin/bash
set -e

if [ "$1" = ''redis-server'' ]; then
    chown -R redis .
    exec gosu redis "$@"
fi

exec "$@"

¿Por qué no ejecutar los comandos como de costumbre sin que exec los ejecute?

Answer 1

Como dice @Peter Lyons, el uso de exec reemplazará el proceso principal, en lugar de tener dos procesos en ejecución.

Esto es importante en Docker para que las señales se procesen correctamente. Por ejemplo, si Redis se inició sin exec, no recibirá un SIGTERM cuando se docker stop SIGTERM docker stop y no tendrá la oportunidad de apagarse limpiamente. En algunos casos, esto puede llevar a la pérdida de datos o procesos zombie.

Si inicia procesos secundarios (es decir, no utiliza exec), el proceso principal se hace responsable de manejar y reenviar las señales según corresponda. Esta es una de las razones por las que es mejor usar supervisord o similar cuando se ejecutan múltiples procesos en un contenedor, ya que reenviará las señales de manera apropiada.

Answer 2

Piense en ello como una optimización como la recursión de la cola.

Si ejecutar otro programa es el acto final del script de shell, no hay mucha necesidad de que el shell ejecute el programa en un nuevo proceso y lo espere. Usando exec , el proceso de shell se reemplaza a sí mismo con el programa.

En cualquier caso, el valor de salida del script de shell será idéntico ¹ . Cualquier programa originalmente llamado script de shell verá un valor de salida que es igual al valor de salida del programa ejecutado (o 127 si no se puede encontrar el programa).

¹ módulo de esquinas, como un programa que hace algo diferente dependiendo del nombre de su padre.

Answer 3

Sin exec, el proceso de shell padre sobrevive y espera a que el hijo salga. Con exec, el proceso hijo reemplaza el proceso principal por completo, de modo que cuando no hay nada que el padre pueda hacer después de bifurcar al niño, consideraría que exec poco más preciso / correcto / eficiente. En el gran esquema de las cosas, creo que probablemente sea seguro clasificarlo como una optimización menor.

sin ejecutivo

• se inicia el shell primario
• padre shell bifurca niño
  • niño corre
  • salidas infantiles
• salidas de shell principal

con el exec

• se inicia el shell primario
• el shell del padre bifurca al niño, se reemplaza a sí mismo con el niño
• programa hijo se ejecuta tomando el proceso de la cáscara
• salidas infantiles