Ejecución no interactiva de comandos administrativos de Linux para agentes desatendidos

Qué es

La mayoría de las herramientas de línea de comandos de Linux se diseñaron para una terminal interactiva: paginan la salida extensa, solicitan confirmación antes de acciones destructivas y dan formato a números y fechas según la configuración regional de la sesión. Una sesión desatendida de un agente no tiene a nadie que recorra la salida paginada, responda a una solicitud o note un cuelgue, así que cada uno de esos comportamientos predeterminados necesita una anulación explícita.

Por qué importa

Un comando que se bloquea esperando un paginador o una respuesta a «¿está seguro? [y/N]» no falla: se queda colgado hasta que algo agota el tiempo de espera más arriba en la pila, lo cual es más difícil de diagnosticar que un error inmediato. Un comando que se ejecuta con éxito pero reformatea su salida numérica o de fecha según una configuración regional equivocada produce una salida que un analizador interpreta mal de forma silenciosa.

Cómo aplicarlo

• Desactivar los paginadores de forma explícita en lugar de confiar en los valores predeterminados: pasar --no-pager a las herramientas que lo admiten (journalctl --no-pager, systemctl --no-pager) y exportar SYSTEMD_PAGER=cat y PAGER=cat como alternativa general para cualquier cosa que consulte esas variables.
• Evitar las solicitudes interactivas del gestor de paquetes: en Debian/Ubuntu, DEBIAN_FRONTEND=noninteractive apt-get install -y <pkg>; en sistemas de la familia RHEL/Fedora, dnf install -y <pkg> (o yum install -y); pasar siempre un -y/--assumeyes explícito en lugar de depender de que un frontend no interactivo lo asuma de forma silenciosa.
• No depender nunca de una solicitud interactiva de contraseña de sudo en una sesión desatendida: sudo -n <command> falla de inmediato con un código de salida distinto de cero si se requeriría una contraseña, en lugar de quedar colgado en una solicitud sin terminal para responderla, que es exactamente el modo de fallo que conviene detectar de forma temprana y explícita.
• Acotar con timeout <seconds> <command> cada comando que pueda colgarse por contención de red o de bloqueos; comprobar $? después, ya que timeout sale con el código 124 específicamente cuando tuvo que matar el comando, lo cual distingue un tiempo de espera agotado del propio fallo del comando (con --preserve-status, timeout sale en cambio con el código del propio comando incluso tras agotarse el tiempo, lo cual oculta esa distinción).
• Establecer una configuración regional analizable antes de extraer la salida de un comando: LC_ALL=C <command> (o LC_ALL=C.UTF-8) impone un formato de números, puntos decimales y cadenas de fecha estable y no localizado, y se lee del entorno del proceso como una de las variables estándar que consulta todo programa basado en la biblioteca C.
• Establecer TERM=dumb (o dejarla sin definir) cuando no hay una terminal real conectada, para que las herramientas que consultan TERM para determinar capacidades de color o cursor no emitan secuencias de escape ANSI en la salida capturada; capturar y comprobar el código de salida de cada comando de forma explícita, en lugar de confiar únicamente en el texto de salida para indicar el éxito.

Trampas

• Añadir -y a un gestor de paquetes sin establecer también la variable de frontend no interactivo, lo cual sigue permitiendo que algunas solicitudes de conffile o de debconf bloqueen en sistemas de la familia Debian.
• Tratar cualquier salida distinta de cero de sudo -n como un fallo del propio comando; sudo -n sale con el código 1 e imprime sudo: a password is required cuando la regla exige una contraseña, así que conviene comprobar stderr en busca de ese mensaje antes de reintentar o escalar a una persona.
• Olvidar que --no-pager y PAGER=cat cubren rutas de fallo distintas: una herramienta que invoca less directamente, ignorando $PAGER, sigue necesitando su propia opción de desactivar el paginador.