The Samba-Bugzilla – Bug 4977
rsync: failed to set times on
Last modified: 2008-07-26 10:13:15 UTC
Hello, I'm using the backup script from http://www.mikerubel.org/computers/rsync_snapshots/ for some time now without probs.
But lately (like 2 weeks) rsync gives me errors like these:
rsync: failed to set times on "/root/snapshot/home/hourly.0/var/www/localhost/htdocs/squirrelmail/plugins/ldapuserdata/doc/ldapuserdata": Function not implemented (38)
But it continues to backup... but i don't know if the backup actually worked...
It also exits like this:
rsync error: some files could not be transferred (code 23) at main.c(980) [sender=2.6.9]
So i guess that some files aren't backupped :O
Ehm i don't know if you want more information, if so, let me know.
I did tried for the search function but i couldn't find any answer...
Ah yes the command i use is:
-va --delete --delete-excluded \
(In reply to comment #0)
> Hello, I'm using the backup script from
> http://www.mikerubel.org/computers/rsync_snapshots/ for some time now without
> But lately (like 2 weeks) rsync gives me errors like these:
> rsync: failed to set times on
> Function not implemented (38)
That means rsync issued a system call to set the times but the operating system returned an error. Such errors usually are not rsync's fault. Try setting the times of that file manually using "touch --reference=/home/var/www/localhost/htdocs/squirrelmail/plugins/ldapuserdata/doc/ldapuserdata /root/snapshot/home/hourly.0/var/www/localhost/htdocs/squirrelmail/plugins/ldapuserdata/doc/ldapuserdata" to see if you get the same error.
> But it continues to backup... but i don't know if the backup actually worked...
Rsync considers most filesystem errors non-fatal: it reports them but continues with the copy. You can usually assume that all files are copied correctly except those specifically mentioned in error messages.
> It also exits like this:
> rsync error: some files could not be transferred (code 23) at main.c(980)
> So i guess that some files aren't backupped :O
That message is just referring to the failure to set times. If some files were not copied, rsync would have printed additional errors about that.
Well i tried your command and it worked without errors...
But i saw also that all files were symlinks, maybe thats the reason why it doesnt works?
(In reply to comment #3)
> Well i tried your command and it worked without errors...
> But i saw also that all files were symlinks, maybe thats the reason why it
> doesnt works?
That explains it. I bet rsync is trying to call lutimes to set the symlink times but the kernel doesn't support it. Since support for lutimes was added to Linux in version 2.6.22, this could happen if you build rsync on a system with kernel >= 2.6.22 and run the result on a system with kernel < 2.6.22. Is this your situation?
Symlink mtimes usually don't mean anything terribly important, so you probably don't need to worry about the errors. If you want them to go away, rebuild rsync on the system that is running it and use that copy of rsync.
I will look tonight for that, but the rsync was builded on the same system i use the script with so it must be built with the kernel my system is running with....
You can comment out the define of HAVE_LCHMOD in config.h if configure thought you had lchmod(), but it's not really working.
Good point, except the relevant system call is lutimes, controlled by HAVE_LUTIMES in config.h.
I had the same problem with my backups, and rebuilding it on the same machine didn't help. I suspect it's because support for lutimes is fs-specific, and I have ext3 (which supports lutimes) on /home (where the build was done), and reiserfs (which apparently does not support lutimes) on /volumes/backup (where the backups are stored)
A rebuild with HAVE_LUTIMES forcibly undefined does not give the error.
I think a real solution would be for rsync to detect lutimes support per-fs at runtime, before attempting to use it. I'd be happy if it never bothered to try, or not unless given something like --have_lutimes. I'm not happy having the default be to throw a bunch of errors about something I don't care about that can't be done on that disk anyway.
[polyergic@seneschal ~]$ uname -a
Linux seneschal 18.104.22.168-1 #1 SMP Sat Aug 4 18:59:20 UTC 2007 i686 AMD_Athlon(tm)_Processor PLD Linux
Why not upgrade to 3.0.0 then? This is one of the things that is improved -- it doesn't bother to output an error about failing to set the time on a symlink.
(In reply to comment #8)
> I suspect it's because support for lutimes is fs-specific, and I
> have ext3 (which supports lutimes) on /home (where the build was done)
> Linux seneschal 22.214.171.124-1 #1 SMP Sat Aug 4 18:59:20 UTC 2007 i686
BTW: lutimes isn't going to work on any filesystem with a kernel before 2.6.22. For HAVE_LUTIMES, the configure script tests only whether the "lutimes" function exists in glibc as a non-stub, not whether it actually works. Thus, if your copy of glibc was built on a machine with kernel >= 2.6.22, it will contain a non-stub lutimes and rsync's HAVE_LUTIMES test will pass.
Well indeed i use the 2.6.21 kernel and im building a 2.6.22 kernel right now.
Version 3 isnt out on gentoo isnt?
(In reply to comment #11)
> Version 3 isnt out on gentoo isnt?
Version 3.0.0 has not been released yet, but you could use the current pre-release, rsync 3.0.0pre2 . I don't know whether Gentoo offers the pre-releases, but you could always compile and install rsync from source yourself.