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.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2060248
Title:
MRE updates of rabbitmq-server for Jammy,Focal
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rabbitmq-server/+bug/2060248/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
