GNU/Linux >> LINUX-Kenntnisse >  >> Linux

/usr/bin/perl:schlechter Interpreter:Textdatei beschäftigt

Dies geschieht, weil die Skriptdatei zum Schreiben geöffnet ist, möglicherweise durch einen bösartigen Prozess, der nicht beendet wurde.

Lösung:Überprüfen Sie, welcher Prozess noch auf die Datei zugreift, und beenden Sie ihn.

Beispiel:

# /root/wordpress_plugin_updater/updater.pl --wp-path=/var/www/virtual/joel.co.in/drjoel.in/htdocs
-bash: /root/wordpress_plugin_updater/updater.pl: /root/perl/bin/perl: bad interpreter: Text file busy

Führen Sie lsof aus (Befehl zum Öffnen von Dateien auflisten) für den Skriptnamen:

# lsof | grep updater.pl
sftp-serv 4416            root    3r      REG            144,103    11043   33046751 /root/wordpress_plugin_updater/updater.pl

Beenden Sie den Prozess anhand seiner PID:

kill -9 4416

Versuchen Sie nun, das Skript erneut auszuführen. Es funktioniert jetzt.

# /root/wordpress_plugin_updater/updater.pl --wp-path=/www/htdocs
Wordpress Plugin Updater script v3.0.1.0.
Processing 24 plugins from

Wenn das Skript in Windows oder einem anderen Betriebssystem mit unterschiedlichen "nativen" Zeilenenden bearbeitet wurde, könnte es so einfach wie CR(^M) sein "versteckt" am Ende der ersten Zeile. Vi Improved kann so eingestellt werden, dass es versteckt wird dieses nicht native Zeilenende. In meinem Fall habe ich einfach die anstößige erste Zeile in VI erneut eingegeben und der Fehler ist verschwunden.


Ich vermute, Sie sind auf dieses Problem gestoßen.

Der Linux-Kernel generiert einen bad interpreter: Text file busy Fehler, wenn Ihr Perl-Skript (oder irgendeine andere Art von Skript) zum Schreiben geöffnet ist, wenn Sie versuchen, es auszuführen.

Sie sagen nicht, was die plattenintensiven Prozesse gemacht haben. Ist es möglich, dass einer von ihnen das Skript für Lese- und Schreibzugriff geöffnet hatte (auch wenn es eigentlich nichts schrieb)?


Dies hat immer damit zu tun, dass der Perl-Interpreter (/usr/bin/perl) nicht erreichbar ist. Tatsächlich passiert es, wenn ein Shell-Skript läuft oder awk oder was auch immer auf dem #! Zeile oben im Skript.

Die Ursache kann viele Dinge sein ... Perms, gesperrte Datei, Dateisystem offline und so weiter und so fort.

Es würde natürlich davon abhängen, was genau in dem Moment passiert ist, in dem Sie es ausgeführt haben, als das Problem aufgetreten ist. Aber ich hoffe, die Antwort ist das, wonach Sie gesucht haben.


Linux
  1. So beheben Sie „/usr/bin/dirmngr“:Keine solche Datei oder kein solches Verzeichnis

  2. /usr/bin vs. /usr/local/bin Unter Linux?

  3. Linux – Zusammenführen von /usr/bin und /usr/sbin in /bin (gnu/linux)?

  4. Installieren Sie Binärdateien in /bin, /sbin, /usr/bin und /usr/sbin, Interaktionen mit --prefix und DESTDIR

  5. Berechtigung für Composer in /usr/local/bin/ verweigert

./configure :/bin/sh^M :schlechter Interpreter

Wechseln Sie das Verzeichnis und führen Sie die Datei in einem Befehl aus

Was ist der Unterschied zwischen #!/usr/bin/env bash und #!/usr/bin/bash?

cmake --version zeigt auf /usr/bin/cmake, während cmake auf /usr/local/bin zeigt

Unterschied zwischen /bin und /usr/bin

#!/bin/sh vs. #!/bin/bash für maximale Portabilität