The errors column is 0. The drop column is 18. The second bit number is the number of packets which should grow. At least that is how I read it. Column makes it more readable in a terminal but not so much in an email.

On 12/21/23 14:18, Alex wrote:
Can someone help me determine if these errors are normal or if this could somehow be the cause? I've removed the last three columns for readability - they were all zeros.

# column -t /proc/net/dev
Inter-|      Receive    |        Transmit
face         |bytes     packets  errs      drop  fifo  frame  compressed  multicast|bytes  packets    errs    drop  fifo lo:          133093161  146045   0         0     0     0      0   0                133093161  146045  0     0     0 ens18:       166999724  256655   0         16    0     0      0   0                167638513  218267  0     0     0

The "errs" for ens18 are steadily increasing, but the "drop" column is steady. It's also curious the errors on loopback would also be increasing?

Other ideas on how to troubleshoot this would be greatly appreciated.

Thanks,
Alex

On Wed, Dec 20, 2023 at 9:27 PM Alex <mysqlstud...@gmail.com <mailto:mysqlstud...@gmail.com>> wrote:

    Hi,

    On Wed, Dec 20, 2023 at 11:03 AM Kevin Korb via rsync
    <rsync@lists.samba.org <mailto:rsync@lists.samba.org>> wrote:

        What is the error?  I assume you know that with that syntax the
        filelist.txt is local rather than remote.


    Yes, I do know it refers to the list of local files.

    There is no error - it just hangs indefinitely until some timeout
    period. This is what it looks like on the remote side:

    $ ps ax|grep rsync
      324075 ?        Ss     0:00 rsync --server -vvvvlogDtpRe.LsfxCIvu
    . /var/tmp/one/
      324094 ?        S      0:00 rsync --server -vvvvlogDtpRe.LsfxCIvu
    . /var/tmp/one/

    On the local side, with a few -vvvv added to rsync, I see this:

    recv_file_list done
    get_local_name count=9 /var/tmp/one/
    generator starting pid=324075
    delta-transmission enabled
    recv_generator(config1.cf <http://config1.cf/>,0)
    config1.cf <http://config1.cf/> is uptodate
    send_files(0, config1.cf <http://config1.cf/>)

    then it just stalls until it eventually times out. However, if I
    remove any one of the nine files from the filelist, it completes
    normally.

    It actually also exhibits the same problem without a filelist at all
    - as long as I'm transferring multiple files, it fails. I suppose if
    I were syncing a directory with less than nine files, it might
    succeed, but local directory to any remote directory on this one
    server fails.

    This also isn't a disk space or inode problem or corrupt filesystem
    problem - the same command works from a different host to this one
    problematic host without a problem.

    I've also confirmed the open file limit is large enough on both sides:

    # ulimit -n
    50000

    I've now spent hours and hours trying to isolate and troubleshoot
    this problem. It really feels like it's somehow related to the
    number of files being transferred, not the size of the files. If I
    break up a directory into multiple attempts, I can eventually
    transfer all the files (maybe 40 in total), but trying to send all
    40 files at once and none get transferred.

    It almost certainly has something to do with building the initial
    list of files. If that list is too large, the transfer fails, even
    if the majority of the files in the source are already in the
    destination.

    It also happens when I'm pushing the files to the destination or
    pulling them from the remote to local.

    Thanks,
    Alex






        On 12/20/23 09:50, Alex via rsync wrote:
         > Hi, I've been using rsync on fedora over ssh to sync
        directories for
         > decades, but suddenly having a problem with transferring
        multiple files
         > at a time to one specific host using --files-from. I can't
        think of what
         > might have changed to have caused this. Using rsync to
        transfer a single
         > file to this problematic host works successfully. It appears
        to be
         > related to the number of files in the --files-from filelist.
        More than
         > nine and it stalls; less than nine and it finishes
        successfully. I'm
         > using the same version of rsync on both sides.
         >
         > (Server) Protocol versions: remote=31, negotiated=31
         > (Client) Protocol versions: remote=31, negotiated=31
         >
         > When running the following command, it appears to collect the
        list of
         > files to be transferred, successfully makes the connection
        with the
         > remote server, but then just stalls. Using strace on the
        remote side
         > shows rsync appears to be waiting for data.
         >
         > rsync -avvvv --files-from=/etc/mail/filelist.txt -e 'ssh -i
         > /root/keys/sync-key-v4' /etc/mail/tmp/ polaris:/var/tmp/one/
         >
         > sync-key-v4 is a passwordless ed25519 key, but I've tried a
        handful of
         > other ed25519 keys.
         >
         > Could it be related to packet size or some kind of network
        disparity?
         > It's not related to the size of the files, as I've tried
        large and small
         > and it doesn't matter - if the number of files exceeds 9, it
        fails.
         >
         >
         >
         >
         >
         >

-- ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,
                 Kevin Korb                      Phone:    (407) 252-6853
                 Systems Administrator           Internet:
        FutureQuest, Inc.               ke...@futurequest.net (work)
                 Orlando, Florida k...@sanitarium.net
        <mailto:k...@sanitarium.net> (personal)
                 Web page: https://sanitarium.net/ <https://sanitarium.net/>
                 PGP public key available on web site.
        ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,

-- Please use reply-all for most replies to avoid omitting the
        mailing list.
        To unsubscribe or change options:
        https://lists.samba.org/mailman/listinfo/rsync
        <https://lists.samba.org/mailman/listinfo/rsync>
        Before posting, read:
        http://www.catb.org/~esr/faqs/smart-questions.html
        <http://www.catb.org/~esr/faqs/smart-questions.html>


--
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,
        Kevin Korb                      Phone:    (407) 252-6853
        Systems Administrator           Internet:
        FutureQuest, Inc.               ke...@futurequest.net  (work)
        Orlando, Florida                k...@sanitarium.net (personal)
        Web page:                       https://sanitarium.net/
        PGP public key available on web site.
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,

--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Reply via email to