¿Qué genera el mensaje "archivo de texto ocupado" en Unix?

¿Qué operación genera el error "archivo de texto ocupado"? No puedo decir exactamente.

Creo que está relacionado con el hecho de que estoy creando un script temporal de Python (usando tempfile) y usando execl a partir de él, pero creo que execl cambia el archivo que se está ejecutando.

Este error significa que algún otro proceso o usuario está accediendo a su archivo. Use lsofpara verificar qué otros procesos lo están usando. Puede usar el killcomando para matarlo si es necesario.

Ha pasado un tiempo desde que vi ese mensaje, pero solía prevalecer en el Sistema V R3 o hace un par de décadas. En aquel entonces, significaba que no podía cambiar el ejecutable de un programa mientras se estaba ejecutando.

Por ejemplo, estaba construyendo un maketrabajo llamado rmk, y después de un tiempo fue autosuficiente. Ejecutaría la versión de desarrollo y haría que construyera una nueva versión. Para que funcione, fue necesario utilizar la solución alternativa:

gcc -g -Wall -o rmk1 main.o -L. -lrmk -L/Users/jleffler/lib/64 -ljl
if [ -f rmk ] ; then mv rmk rmk2 ; else true; fi ; mv rmk1 rmk

Entonces, para evitar problemas con el 'archivo de texto ocupado', la compilación creó un nuevo archivo rmk1, luego movió el antiguo rmka rmk2(cambiar el nombre no fue un problema; desvincularlo fue), y luego movió el nuevo compilado rmk1armk .

No he visto el error en un sistema moderno en bastante tiempo ... pero no siempre tengo programas que se están reconstruyendo.

Esto ocurre cuando intenta escribir en un archivo que el núcleo está ejecutando actualmente, o ejecuta un archivo que está abierto para escritura.

Fuente: http://wiki.wlug.org.nz/ETXTBSY

Ejemplo de reproducción mínima C POSIX ejecutable

Recomiendo comprender la API subyacente para ver mejor lo que está sucediendo.

dormir.c

#define _XOPEN_SOURCE 700
#include <unistd.h>

int main(void) {
    sleep(10000);
}

ocupado.c

#define _XOPEN_SOURCE 700
#include <assert.h>
#include <errno.h>
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>

int main(void) {
    int ret = open("sleep.out", O_WRONLY|O_TRUNC);
    assert(errno == ETXTBSY);
    perror("");
    assert(ret == -1);
}

Compilar y ejecutar:

gcc -std=c99 -o sleep.out ./sleep.c
gcc -std=c99 -o busy.out ./busy.c
./sleep.out &
./busy.out 

busy.outpasa las afirmaciones y perrorsalidas:

Text file busy

entonces deducimos que el mensaje está codificado en glibc.

Alternativamente:

echo asdf > sleep.out

hace la salida de Bash:

-bash: sleep.out: Text file busy

Para una aplicación más compleja, también puede observarla con strace:

strace ./busy.out

que contiene:

openat(AT_FDCWD, "sleep.out", O_WRONLY) = -1 ETXTBSY (Text file busy)

Probado en Ubuntu 18.04, kernel de Linux 4.15.0.

El error no ocurre si unlinkprimero

notbusy.c:

#define _XOPEN_SOURCE 700
#include <assert.h>
#include <errno.h>
#include <fcntl.h>
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>

int main(void) {
    assert(unlink("sleep.out") == 0);
    assert(open("sleep.out", O_WRONLY|O_CREAT) != -1);
}

Luego compila y ejecuta de forma análoga a la anterior, y esas afirmaciones pasan.

Esto explica por qué funciona para ciertos programas pero no para otros. Por ejemplo, si lo haces:

gcc -std=c99 -o sleep.out ./sleep.c
./sleep.out &
gcc -std=c99 -o sleep.out ./sleep.c

eso no genera un error, aunque la segunda gccllamada esté escribiendo en sleep.out.

Un rápido strace muestra que GCC primero se desvincula antes de escribir:

 strace -f gcc -std=c99 -o sleep.out ./sleep.c |& grep sleep.out

contiene:

[pid  3992] unlink("sleep.out")         = 0
[pid  3992] openat(AT_FDCWD, "sleep.out", O_RDWR|O_CREAT|O_TRUNC, 0666) = 3

La razón por la que no falla es que cuando unlink y reescribe el archivo, crea un nuevo inodo y mantiene un inodo colgante temporal para el archivo ejecutable en ejecución.

Pero si solo writesinunlink , entonces intenta escribir en el mismo inodo protegido que el ejecutable en ejecución.

POSIX 7 open()

http://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html

[ETXTBSY]

El archivo es un archivo de procedimiento puro (texto compartido) que se está ejecutando y oflag es O_WRONLY u O_RDWR.

hombre 2 abierto

ETXTBSY

ruta se refiere a una imagen ejecutable que se está ejecutando actualmente y se solicitó acceso de escritura.

En mi caso, estaba tratando de ejecutar un archivo shell (con una extensión .sh) en un entorno csh, y recibí ese mensaje de error.

solo correr con bash funcionó para mí. Por ejemplo

bash file.sh

Si intenta construir phpredisen un cuadro de Linux, es posible que deba darle tiempo para completar la modificación de los permisos del archivo, con un sleepcomando, antes de ejecutar el archivo:

chmod a+x /usr/bin/php/scripts/phpize \
  && sleep 1 \
  && /usr/bin/php/scripts/phpize

No sé la causa, pero puedo contribuir con una solución rápida y fácil.

Acabo de experimentar esta rareza en CentOS 6 después de "cat> shScript.sh" (pegar, ^ Z) y luego editar el archivo en KWrite. Curiosamente no hubo una instancia discernible (ps -ef) de la ejecución del script.

Mi trabajo rápido fue simplemente "cp shScript.sh shScript2.sh" y luego pude ejecutar shScript2.sh. Luego borré ambos. ¡Hecho!

Puede encontrar que esto es más común en los recursos compartidos de red CIFS / SMB. Windows no permite que se escriba un archivo cuando algo más tiene ese archivo abierto, e incluso si el servicio no es Windows (podría ser algún otro producto NAS), es probable que reproduzca el mismo comportamiento. Potencialmente, también podría ser una manifestación de algún problema NAS subyacente vagamente relacionado con el bloqueo / replicación.

Si está ejecutando .sh desde una conexión ssh con una herramienta como MobaXTerm, y si dicha herramienta tiene una utilidad de autoguardado para editar archivos remotos desde la máquina local, eso bloqueará el archivo.

Cerrar y volver a abrir la sesión SSH lo resuelve.

Una de mi experiencia:

Siempre cambio el método abreviado de teclado predeterminado de Chrome mediante ingeniería inversa. Después de la modificación, olvidé cerrar Chrome y ejecuté lo siguiente:

sudo cp chrome /opt/google/chrome/chrome
cp: cannot create regular file '/opt/google/chrome/chrome': Text file busy

Usando strace, puedes encontrar más detalles:

sudo strace cp ./chrome /opt/google/chrome/chrome 2>&1 |grep 'Text file busy'
open("/opt/google/chrome/chrome", O_WRONLY|O_TRUNC) = -1 ETXTBSY (Text file busy)

Encontré esto en PHP cuando lo usaba fopen()en un archivo y luego lo intentaba unlink()antes de usarlo fclose().

No es bueno:

$handle = fopen('file.txt');
// do something
unlink('file.txt');

Bueno:

$handle = fopen('file.txt');
// do something
fclose($handle);
unlink('file.txt');

root@h1:bin[0]# mount h2:/ /x             
root@h1:bin[0]# cp /usr/bin/cat /x/usr/local/bin/
root@h1:bin[0]# umount /x
...
root@h2:~[0]# /usr/local/bin/cat 
-bash: /usr/local/bin/cat: Text file busy
root@h2:~[126]#

ubuntu 20.04, 5.4.0-40-generic
nfsd problem, after reboot ok