Comment 10 for bug 2060248

> I thought wow, what a coincidence, maybe too much of a coincidence. It turns out that this default is
> _already_ available in the current Jammy version 3.9.13. Debian has set the cap via systemd service since
> 9 years ago[0]!
>
> ubuntu@ip-172-31-36-170:~$ sudo systemctl show rabbitmq-server.service --property=LimitNOFILE
> LimitNOFILE=65536

So looking at the upstream release notes, where it says:

> 1. Pick a new limit value they would like to use, for instance, 100K
> 2. Set the maximum open file handle limit (for example, via `systemd`
> or similar tooling) for the OS user used by RabbitMQ to 100K
> 3. Set the ERL_MAX_PORTS environment variable to 100K

What I would like to determine is potential regressions on an update due to this change.

So let's imagine some scenarios:

a) jammy package, with the 65546 limit in the systemd unit
If the user wants to raise that limit, is it a matter of just bumping LimitNOFILE in the systemd unit? Assuming yes, and the new limit was set via an override (and not by editing the unit directly in /lib/systemd/system), and is working, what happens if they upgrade to the version from this update? I assume that bumped limit would be ignored, because now the kernel limit is ignored, and rabbit uses another mechanism to set the maximum concurrent connections. Can you check if this scenario would indeed regress?

b) with the updated package, how would the user raise the number of concurrent connections? I presume a change to the unit file is in order again. In fact, two changes, if I understood this correctly:
b1) bump LimitNOFile
b2) export ERL_MAX_PORTS to the same value (new directive in the unit: it's not there today)

Is that it for (b)?

If (a) indeed regresses, how could we prevent that regression from happening? Without thinking much, three options jump to my mind:
1) revert the upstream change from 3.9.23 that introduced this
2) have some way to automatically export ERL_MAX_PORTS to match LimitNOFile, maybe with a wrapper script (sounds cumbersome)
3) limit the MRE to 3.9.22, just prior to the change in 3.9.23. Would have to check what we are missing all the way up to 3.9.27 and if it's still worth updating to 3.9.22.

I think that if going with >= 3.9.23, we should at least export ERL_MAX_PORTS in the systemd unit file, so that users checking that file will at least be aware of that variable and what it does. But that would still not solve the possible regression in behavior.

Note I don't think the scenario in (a) would make rabbit fail to start, it would just serve less connections, and eventually services trying to connect would fail, if I understood this correctly.

What do you think?