Watch at EaseHistorias. Respuestas. Perspectiva.

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.

Ilustración técnica original: ¿Linux dice “Text file busy”? Prueba el propietario del ejecutable antes de reemplazarlo — path and inode evidence
Ilustración técnica original: Antes de cambiar, registra ruta, ruta resuelta, dispositivo, inode, modo, propietario, hash y procesos relacionados. Watch at Ease

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.

Ilustración técnica original: ¿Linux dice “Text file busy”? Prueba el propietario del ejecutable antes de reemplazarlo — replacement and restart boundary
Ilustración técnica original: Después comprueba PID nuevo, identidad del ejecutable, versión, salud, registros y capacidad de reversión. Watch at Ease