Неожиданная ошибка произошла ошибка при переименовании временного файла текстовый файл занят ubuntu

Ответ 1

Эта ошибка означает, что какой-либо другой процесс или пользователь обращаются к вашему файлу. Используйте lsof, чтобы проверить, какие другие процессы используют его. Вы можете использовать команду kill, чтобы убить ее, если это необходимо.

Ответ 2

Это время, так как я видел это сообщение, но он был распространен в System V R3 или около двух десятков лет назад. В то время это означало, что вы не могли изменить исполняемый файл программы во время его запуска.

Например, я создавал make workalike под названием rmk, и через некоторое время он был самоподдерживающимся. Я бы запустил версию разработки и создал новую версию. Чтобы заставить его работать, необходимо использовать обходное решение:

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

Итак, чтобы избежать проблем с «загруженным текстовым файлом», сборка создала новый файл rmk1, а затем переместила старый rmk в rmk2 (переименование не было проблемой, было отключено) и затем переместил вновь построенный rmk1 в rmk.

Я давно не видел ошибки в современной системе… но я не все, что часто перестраивает программы.

Ответ 3

  Это происходит при попытке записи в файл, который в данный момент выполняется ядром, или при выполнении файла, который в данный момент открыт для записи.

Источник: http://wiki.wlug.org.nz/ETXTBSY

Ответ 4

Пример минимального запуска C POSIX

Я рекомендую понять базовый API, чтобы лучше видеть, что происходит.

sleep.c

#define _XOPEN_SOURCE 700
#include <unistd.h>

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

busy.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);
}

Скомпилируйте и запустите:

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

busy.out передает утверждения, а perror выводит:

Text file busy

поэтому мы делаем вывод, что сообщение жестко закодировано в самом glibc.

В качестве альтернативы:

echo asdf > sleep.out

выводит Bash:

-bash: sleep.out: Text file busy

Для более сложных приложений вы также можете наблюдать это с помощью strace:

strace ./busy.out

который содержит:

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

Протестировано в Ubuntu 18.04, ядро Linux 4.15.0.

Ошибка не произойдет, если вы unlink сначала

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);
}

Затем скомпилируйте и запустите аналогично приведенному выше, и эти утверждения пройдут.

Это объясняет, почему это работает для определенных программ, но не для других. Например. если вы делаете:

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

это не приводит к ошибке, даже если второй вызов gcc пишет в sleep.out.

Краткий strace показывает, что GCC сначала отменяет связь перед записью:

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

содержит:

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

Причина, по которой он не перестает работать, заключается в том, что когда вы unlink переписываете файл, он создает новый индекс и сохраняет временный висячий индекс для исполняемого исполняемого файла.

Но если вы просто write без unlink, то он пытается записать в тот же защищенный инод, что и исполняемый исполняемый файл.

POSIX 7 open()

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

[ETXTBSY]

Этот файл представляет собой файл чистой процедуры (общий текст), который выполняется и имеет значение O_WRONLY или O_RDWR.

человек 2 открытый

ETXTBSY

pathname относится к исполняемому образу, который в данный момент выполняется, и был запрошен доступ для записи.

Ответ 5

В моем случае я пытался выполнить файл оболочки (с расширением .sh)
в среде csh, и я получал это сообщение об ошибке.

просто работает с bash, это сработало для меня.
Например

bash file.sh

Ответ 6

Не знаю причину, но я могу способствовать быстрой и легкой работе.

Я просто испытал эту эту странность в CentOS 6 после «cat > shScript.sh» (paste, ^ Z), а затем редактировал файл в KWrite. Как ни странно, не было видимого экземпляра (ps -ef) выполнения script.

Моя быстрая работа была просто «cp shScript.sh shScript2.sh», после чего я смог выполнить shScript2.sh. Затем я удалил оба. Готово!

Ответ 7

Вы можете обнаружить, что это более распространено в сетевых ресурсах CIFS/SMB. Windows не позволяет писать файл, когда что-то еще открывает этот файл, и даже если служба не Windows (это может быть какой-то другой продукт NAS), он, вероятно, воспроизведет такое же поведение. Потенциально, это может быть также проявление некоторой проблемы с базой NAS, смутно связанной с блокировкой/репликацией.

Ответ 8

Если вы пытаетесь построить phpredis в ящике Linux, вам может потребоваться время, чтобы завершить модификацию разрешений файла с помощью команды sleep перед запуском файла:

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

Ответ 9

Один из моих впечатлений:

Я всегда меняю комбинацию клавиш по умолчанию для Chrome с помощью обратной инженерии. После изменения я забыл закрыть Chrome и выполнил следующее:

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

Используя strace, вы можете найти более подробную информацию:

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)

Ответ 10

Если вы запускаете .sh из ssh-соединения с помощью такого инструмента, как MobaXTerm, и если в указанном инструменте есть утилита автосохранения для редактирования удаленного файла с локального компьютера, он заблокирует файл.

Закрытие и повторное открытие сессии SSH решает ее.

Ответ 11

Я наткнулся на это в PHP при использовании fopen() в файле, а затем попытался unlink() его перед использованием fclose() на нем.

Нехорошо:

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

Хорошо:

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