La liste complète de rsync codes d'erreur

Je suis en train d'écrire un script qui ne instantanés quotidiens de répertoires personnels des utilisateurs. J'ai d'abord faire un essai en utilisant:

rsync -azvrn --out-format="%M %f" source/dir dest/dir

et le rsync opération (en supprimant le -n option).

Je suis en train d'analyser les données en sortie de la sec. Plus précisément, je suis intéressé à en apprendre la cause exacte de la rsync erreur (si l'on s'est produite). Personne ne sait d'

  1. Les plus courantes rsync erreurs et de leurs codes?
  2. Un lien vers une complète rsync code d'erreur de la page?

Le plus important, rsync (au moins sur CentOs 5) ne pas retourner un code d'erreur. Plutôt, il affiche les erreurs en interne et retourne à 0. Comme ainsi:

sending incremental file list
rsync: link_stat "/data/users/gary/testdi" failed: No such file or directory (2)

sent 18 bytes  received 12 bytes  60.00 bytes/sec
total size is 0  speedup is 0.00 (DRY RUN)

rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1039) [sender=3.0.6]

A quelqu'un avait pour analyser rsync erreurs et des suggestions sur la façon de stocker l'rsync retour d'état(s)? Je crois que, lors du transfert de plusieurs fichiers, les erreurs qui pourraient être soulevées par fichier et sont recueillis à la fin, comme indiqué sur la dernière ligne de code ci-dessus.

OriginalL'auteur seebiscuit | 2013-12-23

  1. 34

    Par le rsync "l'homme" de la page, voici les codes d'erreur, il pourrait revenir et ce qu'ils signifient. Si vous êtes un script en bash, vous pouvez regarder $?

     0     Success
 1     Syntax or usage error
 2     Protocol incompatibility
 3     Errors selecting input/output files, dirs
 4     Requested action not supported: an attempt was made to manipulate 64-bit
       files on a platform that cannot support them; or an option was specified
       that is supported by the client and not by the server.
 5     Error starting client-server protocol
 6     Daemon unable to append to log-file
10     Error in socket I/O
11     Error in file I/O
12     Error in rsync protocol data stream
13     Errors with program diagnostics
14     Error in IPC code
20     Received SIGUSR1 or SIGINT
21     Some error returned by waitpid()
22     Error allocating core memory buffers
23     Partial transfer due to error
24     Partial transfer due to vanished source files
25     The --max-delete limit stopped deletions
30     Timeout in data send/receive
35     Timeout waiting for daemon connection

    Je n'ai jamais vu un complet "erreurs les plus fréquentes" liste mais je parie code d'erreur 1 serait au sommet.

    Je ne savais pas que la page de manuel a cette liste! Grâce iandouglas. Btw, je suis d'analyse sur Python. Savez-vous quel est le pythonic l'équivalent de '$?'?
    Oui, si vous utilisez des sous-processus.appel, consulter cette page: python.org/doc//current/library/... résumé: return_code = subprocess.call(...)
    J'ai remarqué que rsync est drôle sur le renvoi des codes d'erreur à la coque. Par exemple, j'ai nourri un mauvais répertoire source et en interne rsync a rapporté 2 erreurs: rsync: link_stat "/data/users/gary/testdi" failed: No such file or directory (2) et rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1039) [sender=3.0.6]. Pourtant, l'impression $? la coquille immédiatement après l'appel renvoyé 0.
    Très étrange en effet. Si c'est toujours à vous donner (code ##) dans le message, vous pouvez simplement regex pour que, peut-être.
    juste pour confirmer ce que @Seebiscuit observée, ce qui est bizarre. Si rsync échoue au cours d'une course parce que la destination est à court d'espace, cela génère (beaucoup de) messages de fin : No space left on device (28) mais il déclare alors rsync error: error in file IO (code 11) at receiver.c(389) [receiver=3.1.0] et se termine avec le code de sortie 11. Semble que la liste des codes d'erreur de l'homme est un "meta list" et il y a plus interne des codes d'erreur (par exemple, 28), qui ne sont cependant pas signalé à la coque.

    OriginalL'auteur iandouglas