« Text file busy » (ETXTBSY) : écriture dans un exécutable en cours d'exécution

Ce que c'est

La page de manuel open(2) documente ETXTBSY comme l'erreur renvoyée lorsqu'un programme tente d'ouvrir en écriture, ou de tronquer, un fichier actuellement mappé comme code programme d'un autre processus, c'est-à-dire un binaire en cours d'exécution. Le noyau refuse, car les pages de code du processus en cours sont directement adossées à ce fichier : laisser une écriture se faire sur place corromprait ce qui est déjà mappé en mémoire. GNU cp la signale ainsi : cp: cannot create regular file '<path>': Text file busy. Le cas inverse existe aussi : execve(2) renvoie ETXTBSY pour un fichier qu'un processus garde encore ouvert en écriture ; lancer un binaire que le processus qui l'écrit n'a pas encore fermé échoue donc, par exemple, avec bash: ./app: Text file busy. Linux 6.11 et 6.12 ont temporairement cessé de refuser les écritures dans les exécutables en cours d'exécution (rétabli dans la version 6.13) ; avec ces versions, un écrasement sur place réussit silencieusement et peut faire planter le programme en cours, de sorte que l'absence d'erreur ne prouve pas que l'écrasement soit sans danger.

Pourquoi c'est important

Cette erreur apparaît dans les scripts de déploiement naïfs : écrasement sur place d'un binaire ou d'un script de serveur de longue durée, ou cp d'une nouvelle build par-dessus un exécutable qu'un superviseur est en train de faire tourner, alors que rien d'autre ne semble anormal dans la build elle-même.

Comment l'appliquer

• Diagnostic : fuser <path> ou lsof <path> indique quel processus a actuellement le fichier ouvert (en tant que code programme en cours d'exécution). On sait ainsi ce qu'il faudrait arrêter, et si c'est attendu.
• Corrections, de la moins à la plus invasive :
  1. Arrêter d'abord le processus en cours, puis écraser le fichier ; acceptable si une courte interruption ne pose pas de problème.
  2. Déployer par renommage plutôt que par écrasement sur place : écrire le nouveau binaire dans un chemin temporaire du même système de fichiers, puis le déplacer sur la cible avec mv. Un renommage est atomique au sein d'un même système de fichiers et ne touche pas à l'inode qu'un processus en cours a déjà mappé. GNU install(1) évite aussi l'erreur, mais en supprimant la destination puis en écrivant un nouveau fichier, ce qui laisse une courte fenêtre pendant laquelle le chemin est absent ou incomplet. L'ancien processus continue de tourner sur l'ancien inode, désormais délié, jusqu'à sa fin naturelle, tandis que la prochaine invocation de la commande utilise immédiatement le nouveau fichier, sans erreur « busy » et sans interruption de service.
  3. Éviter cp ou les redirections tronquantes (>, ouverture avec O_TRUNC) vers un chemin susceptible d'être le binaire en cours d'exécution dans tout script de déploiement ; adopter partout où des binaires sont mis à jour la règle « copier, puis renommer ».
• Non fiable : réessayer l'écriture en boucle. Le fichier reste occupé tant que le processus tourne, ce qui peut durer indéfiniment pour un serveur de longue durée ; réessayer ne résout donc rien, seul un changement de stratégie d'écriture le fait.

Pièges

• Croire que l'erreur signifie que le fichier est corrompu ou que les permissions sont incorrectes ; ce n'est ni l'un ni l'autre : le fichier est simplement utilisé en tant que code exécutable.
• Compter sur l'erreur pour protéger les scripts shell en cours d'exécution : le noyau ne verrouille pas le fichier d'un script, donc un écrasement sur place réussit, et bash, qui lit les scripts de façon incrémentale, peut exécuter les nouveaux octets en pleine exécution. Déployer aussi les scripts par renommage.