Como fazer com que a leitura e gravação do mesmo arquivo no mesmo pipeline sempre "falha"?

Por que existe uma condição de corrida

Os dois lados de um tubo são executados em paralelo, não um após o outro. Existe uma maneira muito simples de demonstrar isso: execute

time sleep 1 | sleep 1

Isso leva um segundo, não dois.

O shell inicia dois processos filhos e espera que ambos sejam concluídos. Esses dois processos são executados em paralelo: a única razão pela qual um deles sincronizaria com o outro é quando ele precisa esperar pelo outro. O ponto mais comum de sincronização é quando o lado direito bloqueia a espera de dados para ler em sua entrada padrão e é desbloqueado quando o lado esquerdo grava mais dados. O inverso também pode acontecer, quando o lado direito é lento para ler os dados e o lado esquerdo bloqueia em sua operação de escrita até que o lado direito leia mais dados (existe um buffer no próprio pipe, gerenciado pelo kernel, mas tem um tamanho máximo pequeno).

Para observar um ponto de sincronização, observe os seguintes comandos ( sh -ximprime cada comando à medida que o executa):

time sh -x -c '{ sleep 1; echo a; } | { cat; }'
time sh -x -c '{ echo a; sleep 1; } | { cat; }'
time sh -x -c '{ echo a; sleep 1; } | { sleep 1; cat; }'
time sh -x -c '{ sleep 2; echo a; } | { cat; sleep 1; }'

Brinque com as variações até se sentir confortável com o que observa.

Dado o comando composto

cat tmp | head -1 > tmp

o processo da esquerda faz o seguinte (listei apenas as etapas relevantes para minha explicação):

1. Execute o programa externo catcom o argumento tmp.
2. Aberto tmppara leitura.
3. Embora não tenha chegado ao final do arquivo, leia um trecho do arquivo e grave-o na saída padrão.

O processo da mão direita faz o seguinte:

1. Redirecione a saída padrão para tmp, truncando o arquivo no processo.
2. Execute o programa externo headcom o argumento -1.
3. Leia uma linha da entrada padrão e grave-a na saída padrão.

O único ponto de sincronização é que o 3 direito espera que o 3 esquerdo tenha processado uma linha completa. Não há sincronização entre left-2 e right-1, então eles podem acontecer em qualquer ordem. A ordem em que eles acontecem não é previsível: depende da arquitetura da CPU, do shell, do kernel, em quais núcleos os processos são agendados, de quais interrupções a CPU recebe naquele momento, etc.

Como mudar o comportamento

Você não pode alterar o comportamento alterando uma configuração do sistema. O computador faz o que você manda. Você disse para truncar tmpe ler tmpem paralelo, então ele faz as duas coisas em paralelo.

Ok, há uma “configuração do sistema” que você pode alterar: você pode substituir /bin/bashpor um programa diferente que não seja o bash. Espero que seja desnecessário dizer que esta não é uma boa ideia.

Se você deseja que o truncamento ocorra antes do lado esquerdo do tubo, é necessário colocá-lo fora do pipeline, por exemplo:

{ cat tmp | head -1; } >tmp

ou

( exec >tmp; cat tmp | head -1 )

Eu não tenho ideia de por que você iria querer isso. Qual é o sentido de ler um arquivo que você sabe que está vazio?

Por outro lado, se você deseja que o redirecionamento de saída (incluindo o truncamento) ocorra após cato término da leitura, é necessário armazenar totalmente os dados na memória, por exemplo

line=$(cat tmp | head -1)
printf %s "$line" >tmp

ou grave em um arquivo diferente e mova-o para o lugar. Geralmente, essa é a maneira robusta de fazer as coisas em scripts e tem a vantagem de que o arquivo é gravado por completo antes de ficar visível pelo nome original.

cat tmp | head -1 >new && mv new tmp

A coleção moreutils inclui um programa que faz exatamente isso, chamado sponge.

cat tmp | head -1 | sponge tmp

Como detectar o problema automaticamente

Se seu objetivo era pegar scripts mal escritos e descobrir automaticamente onde eles quebram, desculpe, a vida não é tão simples. A análise de tempo de execução não encontrará o problema de forma confiável porque, às vezes cat, termina a leitura antes que o truncamento aconteça. A análise estática pode, em princípio, fazê-lo; o exemplo simplificado em sua pergunta é capturado por Shellcheck , mas pode não detectar um problema semelhante em um script mais complexo.

A resposta de Gilles explica a condição de corrida. Só vou responder a esta parte:

Existe alguma maneira de forçar esse script a produzir sempre 0 linhas (para que o redirecionamento de E/S para tmp seja sempre preparado primeiro e os dados sejam sempre destruídos)? Para ser claro, quero dizer alterar as configurações do sistema

IDK se já existe uma ferramenta para isso, mas tenho uma ideia de como poderia ser implementada. (Mas observe que isso não seria sempre 0 linhas, apenas um testador útil que captura corridas simples como essa facilmente e algumas corridas mais complicadas. Veja o comentário de @Gilles .) Não garantiria que um script fosse seguro , mas poderia ser uma ferramenta útil em testes, semelhante ao teste de um programa multi-threaded em CPUs diferentes, incluindo CPUs não-x86 fracamente ordenadas como ARM.

Você o executaria comoracechecker bash foo.sh

Use os mesmos recursos de rastreamento/interceptação de chamada do sistema que strace -fe ltrace -fuse para anexar a cada processo filho. (No Linux, esta é a mesma ptracechamada de sistema usada pelo GDB e outros depuradores para definir pontos de interrupção, etapa única e modificar memória/registros de outro processo.)

Instrumentar as chamadas de sistema opene openat: quando qualquer processo em execução sob esta ferramenta fizer uma chamada open(2)de sistema (ou openat) com O_RDONLY, durma por talvez 1/2 ou 1 segundo. Deixe outras openchamadas do sistema (especialmente aquelas incluindo O_TRUNC) serem executadas sem demora.

Isso deve permitir que o gravador vença a corrida em quase todas as condições de corrida, a menos que a carga do sistema também seja alta ou seja uma condição de corrida complicada em que o truncamento não aconteceu até depois de alguma outra leitura. Portanto, a variação aleatória de quais open()s (e talvez read()s ou gravações) estão atrasadas aumentaria o poder de detecção dessa ferramenta, mas é claro sem testar por uma quantidade infinita de tempo com um simulador de atraso que eventualmente cobrirá todas as situações possíveis que você pode encontrar em o mundo real, você não pode ter certeza de que seus scripts estão livres de corridas, a menos que você os leia cuidadosamente e prove que não estão.

Você provavelmente precisaria dele para colocar na lista de permissões (não atrasar open) os arquivos /usr/bine /usr/lib, portanto, a inicialização do processo não demoraria para sempre. (A vinculação dinâmica em tempo de execução tem open()vários arquivos (veja strace -eopen /bin/trueou em /bin/lsalgum momento), embora se o próprio shell pai estiver fazendo o truncamento, tudo bem. Mas ainda será bom para esta ferramenta não tornar os scripts excessivamente lentos).

Ou talvez coloque na lista de permissões todos os arquivos que o processo de chamada não tem permissão para truncar em primeiro lugar. ou seja, o processo de rastreamento pode fazer uma access(2)chamada de sistema antes de realmente suspender o processo que deseja open()um arquivo.

racecheckerem si teria que ser escrito em C, não em shell, mas talvez pudesse usar straceo código de como ponto de partida e não desse muito trabalho para implementar.

Talvez você possa obter a mesma funcionalidade com um sistema de arquivos FUSE . Provavelmente, há um exemplo FUSE de um sistema de arquivos de passagem puro, para que você possa adicionar verificações à open()função que o tornam suspenso para aberturas somente leitura, mas permitem que o truncamento aconteça imediatamente.