On Fri, 28 Aug 2026 22:21:00 +0200, David Uhden Collado <[email protected]> wrote: > > The intention behind the dedicated login class is precisely to avoid > changing the limits globally. > > Codex is somewhat unusual for a user-facing application because it can > behave more like a development workload: it can launch multiple agents, > shells, git, ripgrep, compilers, Python processes, etc. A sufficiently > large or parallel session can therefore hit several of the default > limits at the same time. > > Using a separate login class gives users who actually need higher > limits an explicit and reversible way of getting them, without raising > the default class or system-wide limits for everybody. > > It is not intended to be required for every Codex user. The README says > to use it if Codex actually starts hitting process, memory, or file > descriptor limits, and also says that the values are only starting > points which should be increased as needed. > > Regarding 8G/16G, those values are limits, not reservations. Setting: > > datasize-max=16G > > does not allocate or reserve 16 GB of RAM for Codex. It only allows a > process to grow up to that limit if memory is actually available. > Someone with 16 GB of RAM will not suddenly lose 16 GB to Codex simply > because that limit exists. > > I chose 8G/16G mainly to leave enough headroom for unusually large > workloads while making the distinction between the normal and hard > limits clear. I would be fine with using more conservative example > values if those numbers look excessive, or making the wording even more > explicit that they should be adjusted according to the machine. > > The same applies to openfiles and maxproc. 1024/2048 file descriptors > are not consumed merely because those limits are configured, and a > maxproc limit of 1024 does not cause 1024 processes to be created. They > simply prevent the login class from becoming the first bottleneck during > large parallel workloads. > > I still prefer documenting a login-class solution rather than telling > users to immediately increase kern.maxfiles or kern.maxproc. The latter > changes affect the entire system, whereas login.conf lets the higher > limits be restricted to the account where they are actually needed. > > Perhaps the README could make this distinction clearer and explicitly > say that users on smaller systems should choose lower values, but I > think documenting the login-class approach itself is useful. >
With that logic we should add a dedicated login class for maven for example. On large and complicated project it will fail because it can't open a file. Same for Chrome for example, which also can use a lot of memory. -- wbr, Kirill
