cifs escreve erros no trabalho cron

Question

EDIT: A SOLUÇÃO

Com a ajuda de Tim, determinei que as gravações maiores de dados estavam falhando versus as menores. Por que eles não falharam quando eu executei o script interativamente, eu não sei ... Mas aqui estava a correção (nova opção de montagem do wsize = 4096):

if mount -t cifs -o guest,wsize=4096 //drobonas/public /mnt/drobonas-public; then
...

wsize=4096 é uma gravação muito pequena (o padrão é 14x isso), portanto, posso experimentar o limite. Mas por enquanto estou feliz que funcione.

PERGUNTA ORIGINAL

Eu tenho um script de shell que faz o backup dos nossos repositórios svn. Eu apóio-os, colocando-os em um NAS (um Drobo). O script cuida da montagem e desmontagem do próprio compartilhamento de rede.

O próprio script funciona bem quando eu o executo diretamente, mas quando executado via cron ele parece falhar com alguns erros relacionados ao CIFS que aparecem no syslog. Primeiro, aqui está o script:

#!/bin/sh
# This script tars up a backup of the needed svn repo directories.
# It expects to be run as root so that it can mount the drobo's drive.
# There are probably ways to allow user mounting (via additions to /etc/fstab) but I'm trying to minimize setup steps.
# I personally placed it in a directory for root (/root/bin or /home/root/bin depending on your distro), then used crontab -e (again as root) to schedule it.
# My crontab looked like this (runs at 1:01 AM, on Mon-Fri, as root user):
# 01 01 * * 1-5 /root/bin/svn-backup.sh

# mount our backup drive
if mount -t cifs -o guest //drobonas/public /mnt/drobonas-public; then

    # perform the actual backup - went with tar so we can preserve permissions, etc
    if tar cvpf /mnt/drobonas-public/SvnBackup/svn-backup-temp.tar /home/svnserver/svnconf/ /home/svnserver/svncreaterepo.sh /home/svnserver/svnrepositories/; then

        # if everything worked out, we can do some cleanup

        # remove our oldest backup in the rotation
        rm /mnt/drobonas-public/SvnBackup/svn-backup-3.tar

        # rename the existing backups to reflect the new order
        #mv /mnt/drobonas-public/SvnBackup/svn-backup-4.tar /mnt/drobonas-public/SvnBackup/svn-backup-5.tar
        #mv /mnt/drobonas-public/SvnBackup/svn-backup-3.tar /mnt/drobonas-public/SvnBackup/svn-backup-4.tar
        mv /mnt/drobonas-public/SvnBackup/svn-backup-2.tar /mnt/drobonas-public/SvnBackup/svn-backup-3.tar
        mv /mnt/drobonas-public/SvnBackup/svn-backup-latest.tar /mnt/drobonas-public/SvnBackup/svn-backup-2.tar
        mv /mnt/drobonas-public/SvnBackup/svn-backup-temp.tar /mnt/drobonas-public/SvnBackup/svn-backup-latest.tar

        # do svnadmin dumps as well - helps future-proof things
        /bin/bash /root/bin/svn-dump.sh

        # we're done, so unmount our drive
        umount /mnt/drobonas-public

    else
        # something went wrong, unmount the drive and then exit signalling failure
        umount /mnt/drobonas-public

        exit 1
    fi

else
    # mount wasn't successful, exit signalling failure
    exit 1
fi

Agora, aqui estão as entradas de log (uma nota: parece criar o arquivo "svn-backup-temp.tar" com sucesso, os erros começam a acontecer depois disso):

Jan  5 07:52:01 giantpenguin CRON[2759]: (root) CMD (/root/bin/svn-backup.sh)
Jan  5 07:52:02 giantpenguin kernel: [21139655.823930]  CIFS VFS: Error -4 sending data on socket to server
Jan  5 07:52:02 giantpenguin kernel: [21139655.823961]  CIFS VFS: Write2 ret -4, wrote 0
Jan  5 07:52:02 giantpenguin kernel: [21139655.824007]  CIFS VFS: Write2 ret -112, wrote 0

A última linha de erro aparece várias vezes antes que o script termine. Alguma percepção? Obrigado!

    

Answer 1

Você verificou que os backups estão sendo criados com todo o conteúdo correto?

Existem vários motivos pelos quais você pode estar vendo os erros.

1. Você talvez veja erros puramente informativos relacionados à configuração do atributo do arquivo no momento da criação (durante os comandos tar e mv ). o sistema de arquivos NTFS ou FAT subjacente à montagem CIFS pode não suportar realmente algumas das chamadas do sistema, e isso pode não ser um erro real.

2. Já tentou criar o arquivo tar localmente e copiá-lo para o NAS?

Além disso, você pode ativar alguns logs mais detalhados via (a partir do fscifs README):

echo 7 > /proc/fs/cifs/cifsFYI

cifsFYI functions as a bit mask. Setting it to 1 enables additional kernel logging of various informational messages. 2 enables logging of non-zero SMB return codes while 4 enables logging of requests that take longer than one second to complete (except for byte range lock requests). Setting it to 4 requires defining CONFIG_CIFS_STATS2 manually in the source code (typically by setting it in the beginning of cifsglob.h), and setting it to seven enables all three. Finally, tracing the start of smb requests and responses can be enabled via:

echo 1 > /proc/fs/cifs/traceSMB

Essas duas opções podem fornecer informações suficientes para saber quais devem ser seus próximos passos.

    

Answer 2

Isso cheira a um problema de permissão. Qual é o ID de usuário do usuário ao executar o script manualmente? É o mesmo que o UID que está executando o cron job?

Observe que, se você executar a tarefa cron como raiz, talvez não tenha as permissões necessárias para acessar o material em um sistema de arquivos montado. Tente adicionar o script à guia cron do usuário no cenário de trabalho: crontab -e deve ser seu amigo.