Version-Release number of selected component: rdiff-backup-1.2.8-9.fc19 Additional info: reporter: libreport-2.1.10 cmdline: /usr/bin/python /bin/rdiff-backup --verbosity 6 --create-full-path --exclude-globbing-filelist /tmp/LVMBackup.bash.excludeGlobbingFile.xsMaOPtUXB /tmp/LVMBackup.bash.mountPointsToBackupMountDir.ZlU8zZvACS /tmp/LVMBackup.bash.backupTargetShareMountDir.857rshjYuW/stinkpad.internal.hupie.com executable: /bin/rdiff-backup kernel: 3.11.10-200.fc19.x86_64 runlevel: N 5 type: Python uid: 0 Truncated backtrace: rpath.py:998:listdir:OSError: [Errno 40] Too many levels of symbolic links: '/tmp/LVMBackup.bash.backupTargetShareMountDir.857rshjYuW/stinkpad.internal.hupie.com/rdiff-backup-data/increments/usr/lib/modules/3.11.10-200.fc19.x86_64/kernel/net/netfilter' Traceback (most recent call last): File "/bin/rdiff-backup", line 30, in <module> rdiff_backup.Main.error_check_Main(sys.argv[1:]) File "/usr/lib64/python2.7/site-packages/rdiff_backup/Main.py", line 304, in error_check_Main try: Main(arglist) File "/usr/lib64/python2.7/site-packages/rdiff_backup/Main.py", line 324, in Main take_action(rps) File "/usr/lib64/python2.7/site-packages/rdiff_backup/Main.py", line 280, in take_action elif action == "backup": Backup(rps[0], rps[1]) File "/usr/lib64/python2.7/site-packages/rdiff_backup/Main.py", line 337, in Backup backup_final_init(rpout) File "/usr/lib64/python2.7/site-packages/rdiff_backup/Main.py", line 501, in backup_final_init checkdest_if_necessary(rpout) File "/usr/lib64/python2.7/site-packages/rdiff_backup/Main.py", line 920, in checkdest_if_necessary dest_rp.conn.regress.Regress(dest_rp) File "/usr/lib64/python2.7/site-packages/rdiff_backup/regress.py", line 71, in Regress for rf in iterate_meta_rfs(mirror_rp, inc_rpath): ITR(rf.index, rf) File "/usr/lib64/python2.7/site-packages/rdiff_backup/regress.py", line 197, in iterate_meta_rfs for raw_rf, metadata_rorp in collated: File "/usr/lib64/python2.7/site-packages/rdiff_backup/rorpiter.py", line 92, in Collate2Iters try: relem1 = riter1.next() File "/usr/lib64/python2.7/site-packages/rdiff_backup/regress.py", line 175, in helper for sub_sub_rf in helper(sub_rf): File "/usr/lib64/python2.7/site-packages/rdiff_backup/regress.py", line 175, in helper for sub_sub_rf in helper(sub_rf): File "/usr/lib64/python2.7/site-packages/rdiff_backup/regress.py", line 175, in helper for sub_sub_rf in helper(sub_rf): File "/usr/lib64/python2.7/site-packages/rdiff_backup/regress.py", line 175, in helper for sub_sub_rf in helper(sub_rf): File "/usr/lib64/python2.7/site-packages/rdiff_backup/regress.py", line 175, in helper for sub_sub_rf in helper(sub_rf): File "/usr/lib64/python2.7/site-packages/rdiff_backup/regress.py", line 175, in helper for sub_sub_rf in helper(sub_rf): File "/usr/lib64/python2.7/site-packages/rdiff_backup/regress.py", line 175, in helper for sub_sub_rf in helper(sub_rf): File "/usr/lib64/python2.7/site-packages/rdiff_backup/regress.py", line 174, in helper for sub_rf in rf.yield_sub_rfs(): File "/usr/lib64/python2.7/site-packages/rdiff_backup/restore.py", line 515, in yield_sub_rfs for mirror_rp, inc_pair in collated: File "/usr/lib64/python2.7/site-packages/rdiff_backup/rorpiter.py", line 100, in Collate2Iters try: relem2 = riter2.next() File "/usr/lib64/python2.7/site-packages/rdiff_backup/restore.py", line 566, in yield_inc_complexes items = get_inc_pairs() File "/usr/lib64/python2.7/site-packages/rdiff_backup/restore.py", line 543, in get_inc_pairs dirlist = robust.listrp(inc_rpath) File "/usr/lib64/python2.7/site-packages/rdiff_backup/robust.py", line 100, in listrp dir_listing = check_common_error(error_handler, rp.listdir) File "/usr/lib64/python2.7/site-packages/rdiff_backup/robust.py", line 32, in check_common_error try: return function(*args) File "/usr/lib64/python2.7/site-packages/rdiff_backup/rpath.py", line 998, in listdir return self.conn.os.listdir(self.path) OSError: [Errno 40] Too many levels of symbolic links: '/tmp/LVMBackup.bash.backupTargetShareMountDir.857rshjYuW/stinkpad.internal.hupie.com/rdiff-backup-data/increments/usr/lib/modules/3.11.10-200.fc19.x86_64/kernel/net/netfilter' Local variables in innermost frame: self: <rdiff_backup.rpath.RPath instance at 0x7f088981b4d0>
Created attachment 837830 [details] File: backtrace
Created attachment 837831 [details] File: environ
what does: ls -lad /tmp/LVMBackup.bash.backupTargetShareMountDir.857rshjYuW/stinkpad.internal.hupie.com/rdiff-backup-data/increments/usr/lib/modules/3.11.10-200.fc19.x86_64/kernel/net/netfilter return?
unfortunately that was in a backup that was since deleted.
I don't think there's much we can do here... if you have a link pointing to a directory with a link pointing to that directory rdiff-backup can get too deep. Ideally it would handle this case, but thats more an issue for upstream. Would you care to file a bug on this upstream?
I have this problem again since the last 3 days. # ls -lad jenkins-public.internal.hupie.com/rdiff-backup-data/increments/usr/lib/modules/3.11.6-200.fc19.x86_64/kernel/net/netfilter drwx------. 4 root root 20480 Dec 10 03:35 jenkins-public.internal.hupie.com/rdiff-backup-data/increments/usr/lib/modules/3.11.6-200.fc19.x86_64/kernel/net/netfilter # ls -la jenkins-public.internal.hupie.com/rdiff-backup-data/increments/usr/lib/modules/3.11.6-200.fc19.x86_64/kernel/net/netfilter 1> /dev/null ls: reading directory jenkins-public.internal.hupie.com/rdiff-backup-data/increments/usr/lib/modules/3.11.6-200.fc19.x86_64/kernel/net/netfilter: Too many levels of symbolic links Mounted over nfs through autofs: qnap859:/Backups on /net/qnap859/Backups type nfs (rw,nosuid,nodev,relatime,vers=3,rsize=32768,wsize=32768,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.160.20,mountvers=3,mountport=35030,mountproto=udp,local_lock=none,addr=192.168.160.20) The target of the mount is on my qnap 859 NAS: # mount /dev/md0 on /share/MD0_DATA type ext4 (rw,usrjquota=aquota.user,jqfmt=vfsv0,user_xattr,data=ordered,delalloc,noacl) # uname -a Linux qnap859 3.4.6 #1 SMP Thu Sep 12 06:51:57 CST 2013 x86_64 unknown So it might be that this is not an rdiff bug but something different. I see no links on that path, but the are a _lot_ of symbolic link files in higher directories. Very weird error. I'm baffled.
Yeah, this isn't really a rdiff-backup issue. ;) But I would try checking each one of the links to see if there's a loop or somehow you are getting higher than 32 (I think thats the default number of links you can have in a path). For purposes of rdiff-backup you could exclude /usr/lib/modules or the like, or add --exclude-symbolic-links to exclude them all.
I excluded /usr/lib/modules on (another) failing backup and the problem is gone. Note that this failing backup was failing _after_ doing the real backup, when running rdiff-backup \ --verbosity ${rdiffVerbose} \ --remove-older-than "${backupRemoveOlderThan}" \ --force "${dst}" which is a bit suspicious to me
Yeah, that is odd. Do you have kernel-devel installed on that machine? The only links I see by default under there are: lrwxrwxrwx. 1 root root 37 Mar 31 11:06 build -> /usr/src/kernels/3.14.0-1.fc21.x86_64 lrwxrwxrwx. 1 root root 5 Mar 31 11:06 /usr/lib/modules/3.14.0-1.fc21.x86_64/source -> build
(In reply to Kevin Fenzi from comment #9) > Yeah, that is odd. > > Do you have kernel-devel installed on that machine? The only links I see by > default under there are: > > lrwxrwxrwx. 1 root root 37 Mar 31 11:06 build -> > /usr/src/kernels/3.14.0-1.fc21.x86_64 > lrwxrwxrwx. 1 root root 5 Mar 31 11:06 > /usr/lib/modules/3.14.0-1.fc21.x86_64/source -> build Installed Packages kernel.x86_64 2.6.32-431.el6 kernel.x86_64 2.6.32-431.1.2.0.1.el6 kernel.x86_64 2.6.32-431.3.1.el6 kernel.x86_64 2.6.32-431.5.1.el6 kernel.x86_64 2.6.32-431.11.2.el6 kernel-firmware.noarch 2.6.32-431.11.2.el6 kernel-headers.x86_64 2.6.32-431.11.2.el6 It even odder than that: - When I run the backup script from a login session it works just fine. - When the script is run from a cron job, I get these errors...
Odd indeed. Perhaps dump 'env' in login session and in the cron job and diff them?
Created attachment 882121 [details] environment diff environmet ('set') diff between execution from login session (file 1) and execution from crond (file 2)
Yeah, nothing really stands out to me there. ;(
Just saw the error again. It happens during increment delete, not during normal backup. I use this command: rdiffVerbose=3 backupRemoveOlderThan="1Y" rdiff-backup \ --verbosity ${rdiffVerbose} \ --remove-older-than "${backupRemoveOlderThan}" \ --force "${dst}"
The scripting can be found here: https://github.com/reposerf/lvmBackup
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.