"Text file busy" (ETXTBSY): escrita em um executável em execução

O que é

ETXTBSY está documentado na página de manual open(2) como o erro retornado quando um programa tenta abrir para escrita, ou truncar, um arquivo que está mapeado como texto de programa de outro processo, ou seja, um binário que está em execução. O kernel recusa a operação porque as páginas de código do processo em execução são baseadas diretamente nesse arquivo; permitir uma escrita no próprio arquivo corromperia o que já está mapeado na memória. O cp do GNU reporta o erro como cp: cannot create regular file '<path>': Text file busy. O inverso também existe: execve(2) retorna ETXTBSY para um arquivo que algum processo ainda mantém aberto para escrita, de modo que iniciar um binário cujo processo de escrita ainda não o fechou falha com, por exemplo, bash: ./app: Text file busy. O Linux 6.11 e o 6.12 deixaram temporariamente de recusar escritas em executáveis em execução (comportamento restaurado no 6.13); nessas versões, uma sobrescrita direta é concluída sem erro e pode derrubar o programa em execução, portanto a ausência do erro não prova que a sobrescrita é segura.

Por que importa

O erro aparece em scripts de deploy ingênuos: sobrescrever diretamente o binário ou script de um servidor de longa duração, ou usar cp para copiar um novo build sobre um executável que um supervisor está rodando, enquanto nada mais parece errado com o build em si.

Como aplicar

• Diagnóstico: fuser <path> ou lsof <path> mostra qual processo está com o arquivo aberto (como texto de programa em execução), para que você saiba o que precisaria ser parado e se isso é esperado.
• Soluções, da menos para a mais invasiva:
  1. Parar primeiro o processo em execução e depois sobrescrever o arquivo, o que é aceitável quando uma breve interrupção não é problema.
  2. Fazer o deploy por rename em vez de sobrescrita direta: gravar o novo binário em um caminho temporário no mesmo sistema de arquivos e depois usar mv para colocá-lo sobre o destino. Um rename é atômico no mesmo sistema de arquivos e não toca o inode que um processo em execução já tem mapeado. O install(1) do GNU também evita o erro, mas removendo o destino e gravando um novo arquivo, o que deixa uma janela curta em que o caminho fica ausente ou incompleto. O processo antigo continua rodando com o inode antigo, já desvinculado, até terminar naturalmente, enquanto a próxima invocação do comando usa imediatamente o novo arquivo, sem erro de arquivo ocupado e sem indisponibilidade.
  3. Evitar cp ou redirecionamentos que truncam (>, abertura com O_TRUNC) sobre um caminho que possa ser o binário em execução em qualquer script de deploy; padronizar o fluxo de copiar e depois renomear em todo lugar onde binários são atualizados.
• Não confiável: tentar a escrita novamente em loop. O arquivo continua ocupado enquanto o processo estiver rodando, o que pode ser indefinidamente em um servidor de longa duração; portanto repetir a tentativa não resolve nada, e só mudar a estratégia de escrita resolve.

Armadilhas

• Presumir que o erro significa arquivo corrompido ou permissões erradas; não é nenhum dos dois, o arquivo está apenas em uso ativo como texto executável.
• Esperar que o erro proteja scripts de shell em execução: o kernel não bloqueia o arquivo de um script, então uma sobrescrita direta é bem-sucedida e o bash, que lê scripts de forma incremental, pode executar os novos bytes no meio da execução. Faça o deploy de scripts também por rename.