Which package is responsible for setting rlimits?

[Sam Hartman]

>>>>> "Simon" == Simon McVittie <smcv at debian.org> writes:

I'm assuming that the proposal is to change this for bookworm.
It seems like it's too late in the process to change something like this
for bullseye without more explicit and significant harm documented  than
you have given so far.

    Simon> Rationale: on sysvinit or runit systems, pid 1 is very simple
    Simon> and is unlikely to need to elevate any limits, but sysadmins
    Simon> are expected to restart system services in an unpredictable
    Simon> execution environment (certainly true for systemd, I'm not so
    Simon> sure for runit). On systemd systems, pid 1 is more complex,
    Simon> but part of the value we get for that complexity is that even
    Simon> when sysadmins restart system services, the service receives
    Simon> a known and predictable execution environment, so it does not
    Simon> need to be robust against inheriting a wrong rlimit or other
    Simon> parameters.

At a project level, I mostly don't buy this rationale in the context of
the GR we passed last year.

My reading of that GR is that running alternative init systems for end
users is not a project-level goal.
It may be a goal of individual package maintainers.
Supporting development of alternative init systems is a project level
goal, or at least was at the time we voted on the GR.

So, in terms of how the project thinks about this, I think the question
should be how much  would  the behavior of accepting defaults from init
systems negatively impact the work of someone trying to develop a new
init system.

At one level, they could certainly configure PAM if the particular
situation was unusual.
At another level, if the limits that pam is likely to inherit are going
to be sufficiently broken to hender normal work, that's probably not
good.

I actually think that in most cases inheriting limits would be
acceptable for development, even if it did add some uncertainty for
production use.
I also think that a credible replacement to systemd is going to need to
provide a way to configure resource limits and to allow administrators
to restart services from pid 1 rather than from a random context.

So,I think that by the time development of an alternate init system
progresses to a point where it is being considered by the project as a
credible replacement for systemd, inheriting limits is likely to work
for that system.

----------------------------------------

It may well be that the PAM maintainer wishes to support sysvinit or
other alternate init systems in contexts broader than the development of
an init system.
I don't know; that seems like a decision for the PAM maintainer rather
than debian-devel.

If that is true, then your proposed solution seems reasonable.
If not, then perhaps we should just drop our patch.