At $JOB, our logs are getting swamped with messages saying:

"Too many concurrent connections, refusing"

It's hampering our ability to manage services, e.g.:

# systemctl status ntpd
Failed to get properties: Connection reset by peer

Near as I can tell from a quick read of the source of dbus.c, we're hitting a hard-coded limit of CONNECTIONS_MAX (set to 4096).

I think this is related to the number of connections systemd (pid 1) has to /run/systemd/private:

# ss -x | grep /run/systemd/private | wc -l
4015

But, despite the almost 4k connections, 'ss' shows that there are no connected peers:

# ss -x | grep /run/systemd/private | grep -v -e '* 0' | wc -l
0

- Are there any tunables that would help us mitigate the "Too many concurrent connections, refusing" messages?

- Is my guess about CONNECTIONS_MAX's relationship to /run/systemd/private correct?

I wanted to ask these questions directly to the systemd people, but their mail server is not configured to allow confirmation emails as to sign up to their mailing list:

<systemd-devel-request@lists.freedesktop.org>:
131.252.210.177 does not like recipient.
Remote host said: 550 5.1.1 <systemd-devel-request@lists.freedesktop.org>: Recip
ient address rejected: User unknown in local recipient table
Giving up on 131.252.210.177.