Skip to content

rsync 3.5.1 wrongly listens on IP adress rather than socket #1119

Description

@christian-heusel

We just updated our fleet in Arch Linux to the latest rsync release and following that, saw all of our mirrors fail to synchronize due to the following error:

[2026-10-07T12:59:06+0000] [ALPM] upgraded rsync (3.5.0-1 -> 3.5.1-1)
Oct 07 17:40:34 repos.archlinux.org rsyncd[283295]: rsyncd version 3.5.1-g04355d27 starting, listening on port 873
Oct 07 17:40:34 repos.archlinux.org rsyncd[283295]: bind() failed: Address already in use (address-family 2)
Oct 07 17:40:34 repos.archlinux.org rsyncd[283295]: bind() failed: Address already in use (address-family 10)
Oct 07 17:40:34 repos.archlinux.org rsyncd[283295]: unable to bind any inbound sockets on port 873
Oct 07 17:40:34 repos.archlinux.org rsyncd[283295]: rsync error: error in socket IO (code 10) at socket.c(707) [Receiver=3.5.1-g04355d27]

https://gitlab.archlinux.org/archlinux/infrastructure/-/work_items/876

Upon investigating the issue it turns out that downgrading rsync to 3.5.0 fixes the issue (archlinux/infrastructure!1244), looking through the 3.5.0..3.5.1 changelog it seems like #1075 could be a potential culprit for the issue. (cc @steadytao & @schuelermine)


A few words about our setup (all infrastructure as code can be found in https://gitlab.archlinux.org/archlinux/infrastructure/ in the dbscripts role):

We set an override via /etc/systemd/system/rsyncd.socket.d/override.conf to make the socket listen on a local socket:

[Socket]
ListenStream=
ListenStream=/run/rsyncd.sock

And then proxy to that both SSL and non-SSL traffic so that our mirrors can use it via rsync-ssl:

server {
    listen 873;
    listen [::]:873;

    access_log /var/log/nginx/rsync.archlinux.org/stream.log stream;
    access_log /var/log/nginx/rsync.archlinux.org/stream.log.json json_stream;
    error_log  /var/log/nginx/rsync.archlinux.org/stream.error.log;

    proxy_pass unix:/run/rsyncd.sock;
    proxy_protocol on;
}

server {
    listen      874 ssl;
    listen      [::]:874 ssl;
    server_name rsync.archlinux.org;

    access_log  /var/log/nginx/rsync.archlinux.org/stream.log stream;
    access_log  /var/log/nginx/rsync.archlinux.org/stream.log.json json_stream;
    error_log   /var/log/nginx/rsync.archlinux.org/stream.error.log;

    ssl_certificate     /etc/letsencrypt/live/repos.archlinux.org/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/repos.archlinux.org/privkey.pem;

    proxy_pass unix:/run/rsyncd.sock;
    proxy_protocol on;
}

cc @Antiz96 @jelly

Activity

  1. christian-heusel commented on Oct 7, 2026

    @christian-heusel
    Author

    Here is an explanation of the underlying bug (🤖 -assisted):


    daemon_main() in clientserver.c decides whether it was started by inetd (or by a systemd socket unit with Accept=yes) by calling is_inetd_socket(STDIN_FILENO). This replaced the old is_a_socket() check, which returned true for any socket on stdin.

    The new function only returns true if stdin is:

    • a SOCK_STREAM socket, and
    • connected, with a peer address family of AF_INET or AF_INET6.

    With ListenStream=/run/rsyncd.sock, stdin is a connected AF_UNIX stream socket, so is_inetd_socket() returns 0. The daemon then doesn't take the inetd path and goes on to start_accept_loop() -> open_socket_in(), which tries to bind port 873. That fails with:

    bind() failed: Address already in use (address-family 2)
    unable to bind any inbound sockets on port 873
    

    In 3.5.0 is_a_socket() accepted the AF_UNIX socket, so this setup worked.

  2. steadytao commented on Oct 8, 2026

    @steadytao
    Member

    @christian-heusel Thank you for reporting. We have had some other reports submitted to us we are working through but a release should hopefully be rolled out somewhat soon. If desired, you may replay #1121 onto a patch for 3.5.1 on Arch.

  3. eworm-de commented on Oct 8, 2026

    @eworm-de
    Contributor

    Thanks a lot, @steadytao !

    As a quick fix we reverted 7ee931c yesterday... @christian-heusel do we want to cherry-pick 6eb05b3 instead and push just another package?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions