“/ bin / bash: intérprete incorreto: arquivo de texto ocupado”, embora o editor de arquivos tenha fechado o arquivo

Question

Eu tenho um script no Linux que eu edito no Windows (através do Samba), que começa com a linha shebang #!/bin/bash . Mesmo assim:

• Eu termino de editar, salvar e fechar o arquivo no editor
• verifique se o arquivo não está aberto em nenhum outro lugar
• verifique se o arquivo foi salvo com a linha Unix terminando
• cat do arquivo no Linux e verifique se a edição está presente
• stat do arquivo no Linux e verifique se ele tem o registro de data e hora após a edição

Ainda recebo o erro /bin/bash: bad interpreter: Text file busy quando tento executá-lo por um tempo (cerca de um minuto ou dois). Por quê?

NOTA: o arquivo não é armazenado em cache no cliente. O arquivo é visível no servidor por cat . Também é possível executar /bin/bash nele. É somente quando a linha shebang é usada, ou seja, quando o próprio arquivo é executado, que o erro acima acontece.

    

Answer 1

O Samba suporta algo chamado bloqueio oportunista.

Quando um cliente quer ler um arquivo e ninguém está gravando o arquivo, o Samba dará ao cliente um bloqueio de leitura. Isso permite que o cliente armazene dados em cache sem precisar lê-los repetidamente no servidor. Se outro cliente quiser gravar no arquivo, o Samba emitirá uma solicitação de "bloqueio de bloqueio" para o cliente com o bloqueio, para que ele não seja mais armazenado em cache.

Da mesma forma, quando um cliente quer gravar um arquivo e ninguém mais está acessando o arquivo, o Samba dará ao cliente um bloqueio de gravação. Isso permite que ele armazene em buffer gravações, leituras de cache e assuma que pode ler suas próprias gravações sem ter que incomodar o servidor. Se outro cliente quiser ler ou gravar no arquivo, o Samba emitirá uma solicitação de "bloqueio de bloqueio" para o cliente com o bloqueio, forçando-o a liberar todas as gravações em buffer e parar o armazenamento em buffer e o armazenamento em cache.

O que está acontecendo é que a máquina do Windows mantém um bloqueio de gravação. E como você está acessando o arquivo do host (e não através do Samba), o Samba não tem chance de pedir ao cliente para quebrar o bloqueio. Como resultado, o servidor não tem como saber se o conteúdo do arquivo é utilizável ou se o conteúdo real ainda é conhecido apenas pelo cliente. Até que o bloqueio de gravação seja quebrado, o arquivo não pode ser executado.

Você pode, se desejar, configurar o Samba para não usar oplocks para aquele compartilhamento, arquivo, extensão ou o que fizer sentido. Haverá uma perda de desempenho, pois o armazenamento em cache e o armazenamento em buffer serão reduzidos.