Technology · GUÍA PRÁCTICA
¿Linux dice “Text file busy”? Prueba el propietario del ejecutable antes de reemplazarlo
ETXTBSY es una colisión entre escritura y ejecución, no una pista para usar chmod. Registra ruta e inode, identifica a quien ejecuta y escribe, prepara un candidato separado y verifica por separado el cambio de ruta y el reinicio.

En Linux, “Text file busy” (ETXTBSY) suele indicar que alguien intenta abrir para escritura una imagen que se está ejecutando, o ejecutar un archivo que otro proceso aún mantiene abierto para escritura. Reintentar, cambiar permisos o copiar encima puede ocultar la colisión de propietarios.
Conserva la ruta exacta, dispositivo e inode; identifica el proceso en ejecución y todos los descriptores con escritura. Verifica un candidato separado. Un rename en el mismo sistema de archivos cambia una ruta, pero los procesos existentes conservan la imagen antigua y el reinicio sigue siendo otra compuerta.
No trates ETXTBSY como un problema de chmod
El error describe la relación entre escritura y ejecución, no un bit ejecutable ausente. Conserva el comando y errno; distingue entre un despliegue que pisa el binario activo y un descriptor escribible heredado por fork.
No borres, fuerces una copia ni repitas sin límite sobre un binario de producción. Decide primero si la operación pretendía escribir en sitio, ejecutar un archivo nuevo o reemplazarlo de forma controlada.
Prueba la ruta, el inode y los dos propietarios
Registra identidad con readlink, stat, file y sha256sum. Usa el inventario aprobado, fuser o lsof para identificar ejecutores y escritores. Tras rename, la misma ruta puede señalar otro inode.
Registra también al dueño del ciclo de vida: systemd, contenedor, supervisor o gestor de paquetes. NFS, carpetas compartidas y overlay son límites separados.
Separa la imagen en ejecución de la carrera por un descriptor de escritura
Una rama es un proceso antiguo que ejecuta el inode que se intenta reescribir. La otra es un descriptor escribible del archivo nuevo heredado por fork; execve aún ve un escritor. El issue de Rust reproduce esta segunda carrera.
Dormir o reintentar solo cambia el tiempo. La solución duradera hace explícita la propiedad del descriptor y la entrega de escritura a ejecución, o cambia un candidato separado bajo el propietario del despliegue.
Prepara un candidato separado y cambia una sola ruta deliberadamente
Escribe el candidato en el directorio destino o en una ubicación verificada del mismo sistema de archivos. Comprueba hash, tipo, modo, propietario y firma o procedencia requerida. No ejecutes una descarga no confiable solo por coincidir con un hash de transporte.
rename(2) sustituye atómicamente una entrada y no altera descriptores abiertos. Eso no vuelve atómico un despliegue con varios archivos, NFS, bibliotecas, migraciones o configuración.
Reinicia, verifica y cierra el incidente
Tras el cambio, procesos existentes pueden seguir con el inode antiguo. El propietario del servicio debe reiniciar y comprobar PID, identidad, versión, salud, registros y compatibilidad.
Cierra solo cuando ETXTBSY esté explicado, no queden escritores inesperados, los nuevos inicios usen el artefacto previsto y pase la prueba real de aceptación.
