Comment 19 for bug 2060248

I'm investigating the jammy MRE - specifically on the addition of ERL_MAX_PORTS. I'm not a fan of the ideas I have so far. The concern is that a user may have increased the cap, and on upgrade would silently cap, which could cause failures.

This of course will be documented in the d/changelog, but I don't think a "you didn't look at d/changelog" is a valid excuse to let that behavior happen, it should be expected that if you modify something as simple as the open file handle limit, that should be respected on upgrade.

The current ideas/why I don't like them:

1. parse the systemd unit configuration - add a new line to add the environment variable to the systemd unit on upgrade
    - Just not a fan of parsing like this, in-case the user has made other modifications such as various comments that could mangle the parsing.

2. Remove the addition of this environment variable
    - This diverges from upstream, could cause confusion when looking at upstream docs. This could not be an issue, but I think in this case it should be considered an issue because having a too high value could cause unexpected DoS and be difficult to debug.

3. modify the upstream code to, at runtime, match ERL_MAX_PORTS from the systemd unit, and leave it uncapped in LimitNOFILE is not present
    - Same issue as #2, diverges from upstream. Also, this assumes that the user knowingly disabled the limit in systemd and is not using another mechanism to cap the open file handle limit. This has the potential of not playing nice with whatever mechanism the user decides to use.

Due to this, I am thinking to have the Jammy MRE upgrade to version v3.9.22 instead, as the bug fixes between v3.9.{23..27} are of course nice to have, but I think are fine to skip out on.