Bug 13496 - lseek returned -1, not 2147483648: Invalid argument (22)
Summary: lseek returned -1, not 2147483648: Invalid argument (22)
Alias: None
Product: rsync
Classification: Unclassified
Component: core (show other bugs)
Version: 3.1.2
Hardware: Sparc Solaris
: P5 normal (vote)
Target Milestone: ---
Assignee: Wayne Davison
QA Contact: Rsync QA Contact
Depends on:
Reported: 2018-06-29 12:52 UTC by Peter Koch
Modified: 2018-06-30 08:25 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Peter Koch 2018-06-29 12:52:08 UTC
Dear rsync experts:

We are rsyncing our file servers /home-directory with approx 1TB data every
night by using the following command:

rsync --password-file=/etc/backup.pass -aHA \
      --link-dest=../<backup-dir from last night> \
      /home/ v480@backup::v480/home/<new backup-dir>

The sending server is a Sun machine running Solaris 10, the receiving
machine runs Slackware Linux 14.2.

For a long time we were using rsync 3.0.8 on the Solaris 10 machine and
rsync 3.1.2 on the backup.server and everything was fine.

Two month ago we decided to rsync ACLs as well and this forced us to
upgrade rsync on the Solaris machine to a newer version. I decided that
using the exact same version on both machines would be the best
situation and so I compiled rsync 3.1.2 on the Solaris machine with

sh configure --prefix=/usr; make; make install

Again everything was working fine (including ACLs) but since 3 days
rsync stops every night with the following error message:

rsync: lseek returned -1, not 2147483648: Invalid argument (22)
rsync error: error in file IO (code 11) at fileio.c(249) [sender=3.1.2]

I suspected a largefile-problem, but none of our files is of size >2GB.

Sometimes the rsync-command is successfull when we restart it
in the morning. SOmetimes the problem still happens when the command
is restarted and we then rsync each subdirectoy separately.

When using the verbose-option we see that rsync fails at different
locations within the file tree.

It seems to me that some kind of 2GB-limit is reached. I looked into
the source code to find out why rsync is doing a lseek(2GB). But
this gave me no ideas about what's happening. errno=22 indicates that
lseek was called with invalid parameters. But rsync --versions shows:

rsync  version 3.1.2  protocol version 31
Copyright (C) 1996-2015 by Andrew Tridgell, Wayne Davison, and others.
Web site: http://rsync.samba.org/
    64-bit files, 64-bit inums, 32-bit timestamps, 64-bit long ints,
    socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace,
    append, ACLs, xattrs, iconv, no symtimes, no prealloc

So we do have largefile support.

The only way to reproduce this problem is to rsync the complete 1TB.
Is there any other debugging information that I can print in line 249
of fileio.c and that might help you to diagnose the problem.

Kind regards

Peter Koch
Comment 1 Peter Koch 2018-06-29 16:05:02 UTC
(In reply to Peter Koch from comment #0)

Our Sun Solaris 10 machine is a 64bit system but our
gcc compiler creates 32bit executables if not told

root@v480# file /usr/bin/rsync
/usr/bin/rsync: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, stripped

I was hoping that my problem would go away if rsync was
compiled as a 64bit binary. So I recreated rsync with

sh configure CFLAGS=-m64 --prefix=/usr; make; make install

root@v480# file /usr/bin/rsync
/usr/bin/rsync: ELF 64-bit MSB executable SPARCV9 Version 1, dynamically linked, stripped

But both exectables fail with the same error message

Comment 2 Peter Koch 2018-06-30 08:25:22 UTC
(In reply to Peter Koch from comment #0)

Dear readers:

Problem has been solved, Here's what was going on:

1: I was (partly) wrong when stating that there were
   no files with size >2GB in our /home-directory

2: Both 32bit and 64bit executables on Solaris 10 do
   support largefiles. So does rsync.

3: One of our administrators created a NFS link from
   our mailserver into our fileservers /home-directory
   and for some reason forced the Solaris machine to
   use NFS version 2

4: 3 day ago a file of size>2GB was created on our
   mailserver. rsync detected this file within the
   /home-directory. It had size >2GB but due to the
   NFS version 2 limitation only the first 2GB of this
   file were readable. So lseek(2GB) returned -1

Now I'm using rsync -aHAx instead of rsync -aHA and
everything works fine again

Thank you all for this wonderfull software