यूनिक्स में "टेक्स्ट फ़ाइल व्यस्त" संदेश क्या उत्पन्न करता है?

Question

क्या ऑपरेशन "पाठ फ़ाइल व्यस्त" त्रुटि उत्पन्न करता है? मैं ठीक-ठीक नहीं बता पा रहा हूं।

मुझे लगता है कि यह इस तथ्य से संबंधित है कि मैं एक अस्थायी पाइथन स्क्रिप्ट (टेम्पेफ़ाइल का उपयोग करके) बना रहा हूं और इससे एक्सेल का उपयोग कर रहा हूं, लेकिन मुझे लगता है कि निष्पादित फ़ाइल को चलाने में बदल जाती है।

Answer 1

इस त्रुटि का अर्थ है कि कोई अन्य प्रक्रिया या उपयोगकर्ता आपकी फ़ाइल तक पहुँच रहा है। lsofयह जांचने के लिए उपयोग करें कि अन्य प्रक्रियाएं इसका उपयोग क्या कर रही हैं। killजरूरत पड़ने पर इसे मारने के लिए आप कमांड का इस्तेमाल कर सकते हैं ।

Comments

Text file busyविशिष्ट में त्रुटि, जबकि यह निष्पादित हो रहा है एक निष्पादन को संशोधित करने की कोशिश कर के बारे में है। यहां "टेक्स्ट" इस तथ्य को संदर्भित करता है कि फाइल को संशोधित किया जाना एक चल रहे प्रोग्राम के लिए टेक्स्ट सेगमेंट है । यह एक बहुत ही विशेष मामला है, और सामान्य नहीं है कि आपका उत्तर आपको लगता है। फिर भी, आपका उत्तर पूरी तरह से गलत नहीं है।

— अर्जुनशंकर

टिप्पणी के साथ जवाब पूरा लगता है।

— Penz

ओपी ने पूछा कि कौन सा ऑपरेशन त्रुटि उत्पन्न करता है, न कि त्रुटि के अर्थ के अन्वेषण के लिए।

— वंडरवर्कर

मुझे लगता है कि तथ्य यह है कि यूनिक्स मानती है कि फाइलें "टेक्स्ट फाइल्स" है, इलोजिकल है, मेरे मामले में यह एक बाइनरी फाइल थी जिसने इस त्रुटि को प्रेरित किया।

— फेलिप वेलेड्स

@FelipeValdes नाम आधी सदी पहले की शब्दावली से ऐतिहासिक है। उदाहरण के लिए, मल्टीिक्स में एक प्रोग्राम का टेक्स्ट सेगमेंट लिंक सेगमेंट से अलग था, और पहले भी लोगों ने बाइनरी टेक्स्ट के बारे में बात की थी। stackoverflow.com/a/1282540/833300

— jma

Answer 2

जब से मैंने उस संदेश को देखा है, तब से कुछ समय है, लेकिन यह सिस्टम V R3 में प्रचलित था या दशकों पहले एक अच्छा जोड़ा था। इसके बाद, इसका मतलब था कि जब आप इसे चला रहे थे, तो आप किसी प्रोग्राम को निष्पादन योग्य नहीं बदल सकते थे।

उदाहरण के लिए, मैं makeनामक एक कार्यबल का निर्माण कर रहा था 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।

मैंने काफी समय में एक आधुनिक प्रणाली पर त्रुटि नहीं देखी है ... लेकिन मुझे लगता है कि अक्सर खुद को पुनर्निर्माण करने वाले कार्यक्रम नहीं होते हैं।

Comments

यहाँ एक सुपर त्वरित प्रतिलिपि प्रस्तुत है: echo -e '#include <unistd.h>\nint main(void){sleep (5);return 0;}' > slowprog.c && cc slowprog.c && cp a.out b.out && (./a.out &) ; sleep 1 && cp b.out a.out। त्रुटि संदेश "cp:" नियमित फ़ाइल 'a.out' नहीं बना सकता: पाठ फ़ाइल व्यस्त "मेरे newish फेडोरा पर"।

— अर्जुनशंकर

बेशक, यह उत्तर सही है और इसे +1 मिलता है। आप "यह थोड़ी देर हो चुकी है" अस्वीकरण हटाना चाह सकते हैं।

— अर्जुनशंकर

@ArjunShankar यहां एक आधुनिक लिनक्स पर "डायरेक्ट" सिस्टम कॉल्स के साथ एक सी प्रजनन है: stackoverflow.com/questions/16764946/… GCC आजकल केवल चल रहे निष्पादनयोग्य को अधिलेखित कर सकता है क्योंकि यदि पहले unlinkडिफ़ॉल्ट रूप से होता है।

— सीरो शांतिली 郝海东 冠状 iro i 法轮功 ''

Answer 3

यह तब होता है जब आप उस फ़ाइल पर लिखने और लिखने का प्रयास करते हैं जिसे वर्तमान में कर्नेल द्वारा निष्पादित किया जा रहा है, या उस फ़ाइल को निष्पादित करें जो वर्तमान में लिखने के लिए खुला है।

स्रोत: http://wiki.wlug.org.nz/ETXTBSY

Answer 4

न्यूनतम रननीय C POSIX प्रजनन उदाहरण

मैं बेहतर दिखने के लिए अंतर्निहित एपीआई को समझने की सलाह देता हूं।

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

इसलिए हम मानते हैं कि यह संदेश ग्लिबक में ही हार्डकोड है।

वैकल्पिक रूप से:

echo asdf > sleep.out

बैश आउटपुट बनाता है:

-bash: sleep.out: Text file busy

अधिक जटिल एप्लिकेशन के लिए, आप इसे भी देख सकते हैं strace:

strace ./busy.out

जिसमें है:

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

उबंटू 18.04, लिनक्स कर्नेल 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_RRWR है।

आदमी 2 खुला

ETXTBSY

pathname एक निष्पादन योग्य छवि को संदर्भित करता है जिसे वर्तमान में निष्पादित किया जा रहा है और लिखने की पहुंच का अनुरोध किया गया था।

Comments

अनलिंक केस के लिए तर्क यह है कि फ़ाइल अब उस डायरेक्टरी से एक्सेस नहीं की जा सकती है, लेकिन इनकोड अभी भी रिफंड के साथ है। आप पहले अनलिंक नहीं करते हैं, आप वास्तव में संरक्षित इनोड पर लिखने की कोशिश कर रहे हैं।

— पेन्ज

@Penz टिप्पणी के लिए obrigado, लिएंड्रो। मुझे आश्चर्य है कि क्यों, इसके विपरीत, यदि आप बिना लिखने की कोशिश करते हैं तो क्या यह एक त्रुटि देता है unlink। क्या पहली execकॉल के बाद लिनक्स कभी फाइल को एक से अधिक बार पढ़ता है ?

— सिरो सेंटिल्ली 郝海东 冠状 iro i 法轮功 ''

ETXTBSY जेनरेट करने वाला इनोड प्रोटेक्शन है। अनलिंक किए बिना, कोई भी लिखता है, जो फ़ाइल निष्पादन द्वारा संरक्षित इनोड पर जाता है; अनलिंक के साथ, आपको एक नया इनऑन मिलता है जो संरक्षित नहीं है। (सुनिश्चित नहीं है कि "संरक्षित" यहाँ शब्द है, लेकिन यह विचार है)

— पेनज़

Answer 5

मेरे मामले में, मैं एक csh वातावरण में शेल फ़ाइल (एक्सटेंशन .sh) के साथ निष्पादित करने का प्रयास कर रहा था, और मुझे यह त्रुटि संदेश मिल रहा था।

बस मार के साथ चल रहा है यह मेरे लिए काम किया। उदाहरण के लिए

bash file.sh

Comments

क्या इसमें #!/bin/bashहेडर था?

— पेन्ज

इसमें निम्नलिखित शीर्ष लेख #! / Bin / sh

— Rafayel Paremuzyan

आप का उपयोग करके #!/usr/bin/cshया समतुल्य करने का प्रयास कर सकते हैं ।

— पेन्ज

Answer 6

यदि phpredisलिनक्स बॉक्स पर निर्माण करने की कोशिश की जा sleepरही है, तो आपको फ़ाइल चलाने से पहले, कमांड के साथ, फ़ाइल अनुमतियों को पूरा करने के लिए समय देना पड़ सकता है :

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

Comments

मुझे नहीं लगता chmodकि अनुमतियाँ सेट होने से पहले वापस आ जाएगी। यह एक फ़ाइल सिस्टम समस्या हो सकती है।

— पेन्ज

यह एक डॉकर छवि के अंदर निर्मित हुआ।

— स्टीफन

डॉकर में कई स्टोरेज ड्राइवर हैं, मुझे लगता है कि उनमें से सभी सही नहीं हैं।

— पेन्ज

फिर भी, यह इस बात का अनुभव करने वाले लोगों के लिए एक बहुत अच्छा संकेत है जब निर्माणकर्ता छवि बनाते हैं।

— मैकीज गोल

Answer 7

कारण पता नहीं है, लेकिन मैं एक त्वरित और आसान काम में योगदान कर सकता हूं।

मैं बस "बिल्ली> shScript.sh" (पेस्ट, ^ Z) के बाद CentOS 6 पर इस विषमता का अनुभव किया, फिर KWrite में फ़ाइल का संपादन किया। अजीब तरह से स्क्रिप्ट निष्पादित करने का कोई उदाहरण (ps -ef) नहीं था।

मेरे आसपास का त्वरित कार्य बस "cp shScript.sh shScript2.sh" था, तब मैं shScript2.sh निष्पादित करने में सक्षम था। फिर मैंने दोनों को हटवा दिया। किया हुआ!

Comments

क्योंकि आप अपने समस्या थी निलंबितcat प्रक्रिया। अगली बार ^ डी, नॉट ^ जेड।

— व्लादिमीर पैंटेलेव

काफी सही व्लादिमीर। धन्यवाद! यही मैंने डॉस / सीएमडी प्रॉम्प्ट में किया होगा। पुराने निवास स्थान ... के बाद से नहीं हुआ है :)

— ScottWelker

Answer 8

आपको यह CIFS / SMB नेटवर्क शेयरों पर अधिक सामान्य हो सकता है। Windows किसी फ़ाइल को लिखने की अनुमति नहीं देता है जब किसी और चीज़ में वह फ़ाइल खुली होती है, और भले ही वह सेवा Windows न हो (यह कुछ अन्य NAS उत्पाद हो सकता है), यह संभवतः उसी व्यवहार को पुन: पेश करेगा। संभावित रूप से, यह कुछ अंतर्निहित एनएएस मुद्दे की अभिव्यक्ति भी हो सकता है जो लॉकिंग / प्रतिकृति से संबंधित है।

Answer 9

यदि आप एक ssh कनेक्शन से .sh को MobaXTerm जैसे टूल से चला रहे हैं, और यदि कहा गया है कि टूल में लोकल मशीन से रिमोट फाइल को एडिट करने के लिए ऑटोसेव यूटिलिटी है, जो फाइल को लॉक कर देगा।

SSH सत्र को बंद करना और फिर से खोलना इसे हल करता है।

Answer 10

मेरा एक अनुभव:

मैं हमेशा रिवर्स इंजीनियरिंग के माध्यम से क्रोम के डिफ़ॉल्ट कीबोर्ड शॉर्टकट को बदलता हूं। संशोधन के बाद, मैं क्रोम को बंद करना भूल गया और निम्नलिखित भाग गया:

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

स्ट्रेस का उपयोग करके, आप अधिक विवरण पा सकते हैं:

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)

Answer 11

मैं fopen()एक फाइल पर उपयोग करते समय PHP में इस पर आया था और फिर unlink()उस fclose()पर उपयोग करने से पहले इसे करने की कोशिश कर रहा था।

अच्छा नहीं:

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

अच्छा:

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

Comments

खिड़कियों पर मुझे लगता है? लिनक्स पर आमतौर पर सिस्टम हमें खुली फाइलों को हटाने की अनुमति देता है - निर्देशिका में संदर्भ को समाप्त कर दिया जाता है, लेकिन डेटा (इनोड) केवल तभी फ्रेड किया जाता है जब संदर्भों की संख्या 0. तक पहुँच जाती है

— पेनज़

नहीं, यह सेंटोस पर था।

— dtbarne

यह Linux4 पर परीक्षण किया गया था ext4 फाइलसिस्टम के साथ 4.7.10 और इसने किसी भी त्रुटि का उत्पादन नहीं किया, जैसा कि पेनज़ ने उल्लेख किया है। फ़ाइल सफलतापूर्वक हटा दी गई। शायद dtbarne कुछ विशेष फाइलसिस्टम का उपयोग कर रहा है।

— k3a

यह योनि पर चल रहा था - यह एक साझा फ़ोल्डर होने के कारण हो सकता है।

— dtbarne

Answer 12

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

Comments

कृपया केवल कोड को उत्तर के रूप में पोस्ट न करें, बल्कि यह भी स्पष्टीकरण दें कि आपका कोड क्या करता है और यह प्रश्न की समस्या को कैसे हल करता है। एक स्पष्टीकरण के साथ उत्तर आमतौर पर अधिक सहायक और बेहतर गुणवत्ता के होते हैं, और upvotes को आकर्षित करने की अधिक संभावना होती है।

— मार्क रोटेटेवेल