systemd: retry when the dbus connection returns EAGAIN

[jianghao65536]

Before version 254, systemd used the glibc macro SOMAXCONN to set the backlog. Prior to Linux 5.4, SOMAXCONN was set to 128. If the number of instantaneous connections exceeds this value, newConnection will return EAGAIN, which can cause runc to fail when creating containers.

[kolyshkin]

Maybe this should be t.Fatal, we don't want a bunch of similar errors.

[kolyshkin]

I tried the test from here (without the fix, just the test case) on three different distros:

• Fedora 42: kernel 6.16.10-200.fc42.x86_64, systemd 257.9-2.fc42
• Alma 9: kernel 5.14.0-570.37.1.el9_6.x86_64, systemd 252-51.el9.alma.1
• Alma 8: kernel 4.18.0-553.16.1.el8_10.x86_64, systemd 239-82.el8_10.1

and it does not fail.

This might be because Red Hat has backported systemd fix, so what distro do you recommend to try so we can see the test fails before the fix?

[jianghao65536]

@kolyshkin I can reproduce the issue using Alma 8. The reproducible Vagrantfile is as follows:

Vagrant.configure("2") do |config|
  config.vm.box = "almalinux/8"
  config.vm.hostname = "alma8-vm"

  config.vm.provider "virtualbox" do |vb|
    vb.name = "AlmaLinux8_Vagrant"
    vb.memory = "2048"
    vb.cpus = 2
  end

  config.vm.provision "shell", inline: <<-SHELL
    sudo dnf install -y go
    go version
  SHELL
end

The test result is as follows:

I haven’t tested it on many kernel versions, but based on the commit messages of systemd and glibc, it seems that systemd compiled with glibc versions earlier than 2.31 may encounter the EAGAIN issue.
Systemd related link: systemd/systemd#28018
Glibc related link: bminor/glibc@96958e2