← Back to context

Comment by throw0101a

14 hours ago

> There's lot of annoying things that make it harder to admin for.

It also (AIUI) tries to walk the entire file tree, so have fun with NFS (auto)mounts.

It also amounts to letting off fork bombs: we set up limits for a maximum of 256 process per UID, and regularly get folks asking "what does this 'cannot fork' message mean?": it mean you're trying to DoS the system.

> we set up limits for a maximum of 256 process per UID, and regularly get folks asking "what does this 'cannot fork' message mean?"

The max limit on 64 bit systems is what, 4,194,303? So if you have over 16,000 users per VM this limit makes sense, otherwise it just seems user-hostile.

  • Every process takes some memory and other resource, yes a stale process will pretty much all end up all paged out and not massively in the way of active processes, but they still aren't entirely free so it is more than a bean-counting number.

    Yes, under Linux (and most unix-a-like systems) small processes are cheap to bring up and tear down which is why we create them so much, and it is not uncommon for complex interactive commands and bits of shell scripts to create several¹, but these are all likely to be short-lived so a limit of 256 certainly doesn't seem to be obscenely low to me.

    What could it be doing that requires 256+ processes to be kept around for a prolonged time?

    --------

    [1] made up example: comparing filtered content of two gzipped files and sending the result through a script to send alerts by mail if certain things are found would be 7+ (2x gzip, 2x or more grep, diff, bash, mail or curl depending on what service you are sending alerts through)

  • > The max limit on 64 bit systems is what, 4,194,303? So if you have over 16,000 users per VM this limit makes sense, otherwise it just seems user-hostile.

    And yet we still regularly loads of >100 on our 64 core HPC login codes, and swap is regularly used even with 96G of system memory (we have per UID memory limits too).

    What's hostile is the VSCode (and Codex and Claude) makers developing tools that basically DoS a system because they assume it will operate only on single-user machines.

    (And WTF are you doing that you're forking 256 processes? We have quite a few expensive HPC nodes: use those to build, not the damn login nodes.)

Honestly every developer needs to increase those default limits, they are too low for modern development... So you are just crippling them and a proof of that is they keep getting this error while in their regular workflow

  • I don't even hit 256 on my desktop with a shitton of things open and 75 firefox sandbox processes, much less on a remote server. What in heaven's name are you doing to cross 256?

    (Also this isn't a default limit.)