„Text file busy“ (ETXTBSY): Schreibzugriff auf eine laufende ausführbare Datei

Worum es geht

ETXTBSY ist auf der Manpage open(2) als der Fehler dokumentiert, der zurückgegeben wird, wenn ein Programm eine Datei zum Schreiben öffnen oder kürzen will, die gerade als Programmtext eines anderen Prozesses eingeblendet ist – also eine Binärdatei, die aktiv läuft. Der Kernel verweigert den Zugriff, weil die Code-Seiten des laufenden Prozesses direkt an diese Datei gebunden sind; ein direktes Überschreiben würde das beschädigen, was bereits im Speicher eingeblendet ist. GNU cp meldet den Fehler als cp: cannot create regular file '<path>': Text file busy. Es gibt auch den umgekehrten Fall: execve(2) liefert ETXTBSY für eine Datei, die ein Prozess noch zum Schreiben geöffnet hält. Wird eine Binärdatei gestartet, deren Schreiber sie noch nicht geschlossen hat, schlägt das fehl, zum Beispiel mit bash: ./app: Text file busy. Linux 6.11 und 6.12 haben vorübergehend aufgehört, Schreibzugriffe auf laufende ausführbare Dateien abzulehnen (mit 6.13 wiederhergestellt); dort gelingt ein direktes Überschreiben ohne Meldung und kann das laufende Programm zum Absturz bringen. Ein fehlender Fehler beweist also nicht, dass das Überschreiben unbedenklich ist.

Warum es wichtig ist

Der Fehler tritt bei naiven Deployment-Skripten auf: Eine langlaufende Server-Binärdatei oder ein Skript wird direkt überschrieben, oder ein neuer Build wird per cp über eine ausführbare Datei kopiert, die ein Supervisor gerade ausführt – obwohl am Build selbst nichts auffällig ist.

So wird es angewendet

• Diagnose: fuser <path> oder lsof <path> zeigt, welcher Prozess die Datei gerade geöffnet hat (als laufenden Programmtext). So ist erkennbar, was gestoppt werden müsste und ob das erwartet ist.
• Lösungen, von der am wenigsten bis zur am stärksten eingreifenden:
  1. Zuerst den laufenden Prozess stoppen, dann die Datei überschreiben – vertretbar, wenn ein kurzer Ausfall in Ordnung ist.
  2. Per Rename statt durch direktes Überschreiben deployen: Die neue Binärdatei an einen temporären Pfad auf demselben Dateisystem schreiben und sie dann mit mv über das Ziel verschieben. Ein Rename ist auf demselben Dateisystem atomar und berührt den Inode nicht, den ein laufender Prozess bereits eingeblendet hat. Auch GNU install(1) vermeidet den Fehler, entfernt dafür aber zuerst das Ziel und schreibt dann eine neue Datei; dadurch fehlt der Pfad kurzzeitig oder ist unvollständig. Der alte Prozess läuft weiter auf dem alten, nun nicht mehr verknüpften (unlinked) Inode, bis er von selbst endet, während der nächste Aufruf des Befehls sofort die neue Datei verwendet – ohne Busy-Fehler und ohne Ausfallzeit.
  3. In Deployment-Skripten cp und kürzende Umleitungen (>, Öffnen mit O_TRUNC) auf Pfade vermeiden, die die aktuell laufende Binärdatei sein könnten; überall, wo Binärdateien aktualisiert werden, einheitlich auf Kopieren und anschliessendes Umbenennen setzen.
• Nicht zuverlässig: den Schreibzugriff in einer Schleife wiederholen. Die Datei bleibt belegt, solange der Prozess läuft, bei einem langlebigen Server möglicherweise unbegrenzt. Wiederholen löst also nichts; nur eine andere Schreibstrategie hilft.

Stolpersteine

• Annehmen, der Fehler bedeute, die Datei sei beschädigt oder die Berechtigungen seien falsch; beides trifft nicht zu – die Datei wird schlicht gerade als ausführbarer Text verwendet.
• Erwarten, der Fehler schütze laufende Shell-Skripte: Der Kernel sperrt die Datei eines Skripts nicht. Ein direktes Überschreiben gelingt daher, und bash, das Skripte schrittweise einliest, kann mitten im Lauf die neuen Bytes ausführen. Auch Skripte per Rename deployen.