«Text file busy» (ETXTBSY): escribir en un ejecutable en ejecución

Qué es

ETXTBSY está documentado en la página de manual open(2) como el error que se devuelve cuando un programa intenta abrir para escritura, o truncar, un archivo que está mapeado actualmente como texto de programa de otro proceso; es decir, un binario que se está ejecutando. El kernel lo rechaza porque las páginas de código del proceso en ejecución están respaldadas directamente por ese archivo, y permitir una escritura en el sitio corrompería lo que ya está mapeado en memoria. GNU cp lo notifica como cp: cannot create regular file '<path>': Text file busy. También existe el caso inverso: execve(2) devuelve ETXTBSY si algún proceso aún mantiene el archivo abierto para escritura, de modo que iniciar un binario cuyo proceso escritor todavía no lo ha cerrado falla con un mensaje como bash: ./app: Text file busy. Linux 6.11 y 6.12 dejaron de rechazar temporalmente las escrituras en ejecutables en ejecución (se restauró en 6.13); en esas versiones una sobrescritura en el sitio se completa sin error y puede hacer fallar el programa en ejecución, por lo que la ausencia de error no demuestra que la sobrescritura sea segura.

Por qué importa

El error aparece en scripts de despliegue ingenuos: sobrescribir en el sitio un binario o script de servidor de larga duración, o copiar con cp una compilación nueva sobre un ejecutable que un supervisor está ejecutando en ese momento, aunque la compilación en sí no tenga ningún problema aparente.

Cómo aplicarlo

• Diagnóstico: fuser <path> o lsof <path> muestran qué proceso tiene el archivo abierto en ese momento (como texto de programa en ejecución), de modo que se sabe qué habría que detener y si eso es lo esperado.
• Soluciones, de la menos a la más invasiva:
  1. Detener primero el proceso en ejecución y después sobrescribir el archivo; es aceptable cuando una breve interrupción no es un problema.
  2. Desplegar mediante rename en lugar de sobrescribir en el sitio: escribir el binario nuevo en una ruta temporal del mismo sistema de archivos y luego moverlo con mv sobre el destino. Un rename es atómico dentro del mismo sistema de archivos y no toca el inodo que un proceso en ejecución ya tiene mapeado. GNU install(1) también evita el error, pero lo hace eliminando el destino y escribiendo después un archivo nuevo, lo que deja una ventana breve en la que la ruta no existe o está incompleta. El proceso antiguo sigue ejecutándose con el inodo antiguo, ya desvinculado, hasta que termina de forma natural, mientras que la siguiente invocación del comando usa el archivo nuevo de inmediato, sin error de ocupado y sin tiempo de inactividad.
  3. Evitar cp o las redirecciones que truncan (>, abrir con O_TRUNC) sobre una ruta que pueda ser el binario en ejecución en cualquier script de despliegue; conviene estandarizar el patrón de copiar y luego renombrar en todos los lugares donde se actualicen binarios.
• No es fiable: reintentar la escritura en un bucle. El archivo permanece ocupado mientras el proceso siga ejecutándose, lo cual puede ser indefinido en un servidor de larga duración, así que reintentar no resuelve nada; solo cambiar la estrategia de escritura lo hace.

Trampas

• Suponer que el error significa que el archivo está corrupto o que los permisos son incorrectos; no es ninguna de las dos cosas: el archivo simplemente está en uso activo como texto ejecutable.
• Esperar que el error proteja los scripts de shell en ejecución: el kernel no bloquea el archivo de un script, por lo que una sobrescritura en el sitio se realiza sin error y bash, que lee los scripts de forma incremental, puede ejecutar los bytes nuevos a mitad de la ejecución. Los scripts también deben desplegarse mediante rename.