Primeiro, experimente alguns cronjobs simples e construa a partir daqui:
0 12 * * * user echo 'Hello, World!' >> /tmp/test.log 2>&1
1 12 * * * user ssh anotheruser@anotherhost ls >> /tmp/test.log 2>&1
2 12 * * * user rsync -e ssh anotheruser@anotherhost:/path/to/small/dir /tmp/test-dir >> /tmp/test.log 2>&1
Evite usar muitas opções no início, mas usar 2>&1 é importante para receber mensagens de erro. Você também pode usar 2>/tmp/test-error.log para enviá-los para um arquivo separado. Normalmente, o cron gera um email se, e somente se, houver alguma saída. Este e-mail é enviado para o endereço de e-mail mencionado na variável de ambiente MAILTO definida no crontab ou para o usuário unix local o job é executado como se MAILTO não estivesse configurado. Se você não tiver um servidor de e-mail instalado ou não tiver certeza de como acessá-lo, poderá redirecionar toda a saída para um arquivo. Outra coisa a considerar é configurar a SHELL. Por padrão, o cron usa / bin / sh, que normalmente é bom, e pode até ser um link simbólico para / bin / bash em alguns sistemas, mas se não, você espera usar bash-isms em seu comando, você pode adicionar SHELL=/bin/bash ou o que for apropriado antes de suas listas de empregos.
Outra questão que posso ver com seus crontabs acima são os espaços. Como os comandos funcionam em um shell normal, provavelmente não é o problema, mas seja cauteloso ao usar espaços ao usar certos comandos ssh remotos como: ssh server ls "Music Videos" , espaços em tais comandos precisam ser duplicados devido ao fato de que ambos shell local e shell remoto podem interpretá-los. O comando correto deve ser algo assim: ssh server ls "Music\ Videos" ou ssh server ls '"Music Videos"'
A última coisa que posso pensar é que o ssh está falhando na autenticação. Eu suponho que você esteja usando autenticação de chave pública. Onde sua chave pública está sendo armazenada? Ela está em ~/.ssh/id_rsa como uma chave privada não criptografada ou você a carregou em um Agente de chave pública SSH? Se ele for carregado em um agente porque a cópia em disco está criptografada, será necessário verificar se SSH_AUTH_SOCK está configurado manualmente no crontab para apontar para um agente que estará em execução quando o rsync estiver. Eu normalmente mantenho minhas chaves privadas criptografadas em disco e mantenho o ssh-agent em execução em segundo plano com um caminho de soquete fixo. Por exemplo, eu corro ssh-agent -a /tmp/user.agent seguido de SSH_AUTH_SOCK=/tmp/user.agent ssh-add .ssh/id_rsa para carregar a chave privada no agente. Eu tenho esses dois comandos em um script que eu executo manualmente após cada reinicialização desde que eu preciso digitar uma frase secreta para desbloquear a chave privada. Então eu tenho SSH_AUTH_SOCK=/tmp/user.agent no meu arquivo crontab para meus cronjobs automáticos usarem.