É possível ter um atraso entre o scp e a verificação de novo arquivo

Question

Tem um cronjob que baixa regularmente as coisas:

if ! su scpuser -c "scp ..." > /dev/null 2>&1 || ! [ -f $scptarget ]; then;
  error "did not download stuff"

$scptarget é onde a coisa é baixada e está em um volume diferente do script em execução (mas não em um estado diferente, no mesmo disco rígido que eu acho)

Toda vez que ocorre um erro, entramos e procuramos e o arquivo está lá. Existe uma chance de que a parte que verifica a existência do arquivo seja bem-sucedida se apenas relaxar um pouco? Alternativamente, o SCP poderia estar jogando erros mesmo quando foi bem-sucedido?

(Eu queria que o cara que escreveu isso em primeiro lugar tivesse registrado qual foi o erro real, eu estou meio que agarrando palhas)

Se assim for, eu não quero adicionar um sleep arbitrário a este script, existe algo mais classico que os programadores de bash reais fazem?

    

Answer 1

Eu fiz um strace em um scp de um arquivo. Parece que scp não usa um nome de arquivo temporário como wget , na verdade, verifica a existência do arquivo de destino e o abre com O_WRONLY|O_CREAT . O arquivo de destino deve existir se scp for muito longe para realmente ter dados para gravar.

Não há como haver uma "corrida" entre a existência do arquivo de destino e a verificação de sua existência. O shell precisará obter SIGCHLD de scp exiting para obter o status de saída e decidir que o status é diferente de zero. Tenho certeza que o kernel cuidaria do nome do arquivo existente quando o processo scp sair. A criação de arquivos é supostamente atômica. Não se preocupe em adicionar um sleep , não vai ajudar.

A única maneira de seu código de exemplo chegar ao teste de existência do arquivo de destino ( [ -f $scptarget ] ) é se scp sair com o status 0 (zero). É certamente possível que o arquivo exista, mas tenha uma condição de erro. Você verifica o arquivo $scptarget para correção e integridade quando ocorre um erro? Você pode acabar com um arquivo parcial ou mutilado.

Eu acho que para descobrir o que está acontecendo, você teria que usar 2 if constructos, um para o status de saída de scp e o segundo para a existência do arquivo de destino. Certifique-se de que as mensagens sejam diferentes e registre $? , o status de saída do processo scp .

    

Answer 2

Obtenha o código de erro primeiro (o stderr também pode ser útil. Quem faz o script sem erros de registro ...?). É possível que 'su' ou 'scp' retornem retVal > 0.

Um recorte do código-fonte do SCP para o OSX:

 // I'd put my bet for this case..
 void
 lostconn(signo)
    int signo;
 {
    if (!iamremote)
        fprintf(stderr, "lost connection\n");
    exit(1);
 }

Certifique-se de que após o arquivo de destino da falha é exatamente o mesmo que o arquivo de origem ...

Recorte de su manpage:

EXIT VALUES

On success, su returns the exit value of the command it executed.

If this command was terminated by a signal, su returns the number of this signal plus 128.

If su has to kill the command (because it was asked to terminate, and the command did not terminate in time), su returns 255.

Novamente .. Sem o código de saída ou o conteúdo stderr, não há muito que possamos fazer, a não ser adivinhar ..