macOS 13.5 no longer allows setting system wide ulimits

The default limit is in place because select() uses a fixed size bitmap for file descriptors. If a program that uses select opens more than that many files it will make an out of bounds write. It is probably better to make the file descriptor allocation fail than have memory corruption.<p>All programs that don&#x27;t use select() should raise the limit to the hard limit on startup. Then drop it back down before exec()ing another program. It is a silly dance but that is the cost of legacy. I&#x27;m surprised that these programs that are affected can&#x27;t add this dance in.

At least it&#x27;s only the soft limit. The hard limit isn&#x27;t reduced. The simplest workaround is to wrap the start of the of process with a shell script raising the soft limit before it execs into the application you want to run.

The error message indicates that &quot;Operation not permitted while System Integrity Protection is engaged&quot;.<p>.... and if SIP is turned off?

I&#x27;ve ... always used ulimit on macOS, going back almost a decade. Never heard of using `launchctl` to change it.<p><a href="https:&#x2F;&#x2F;www.google.com&#x2F;search?q=ulimit+mac+site%3Astackoverflow.com&amp;oq=ulimit+mac+site%3Astackoverflow.com" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.google.com&#x2F;search?q=ulimit+mac+site%3Astackoverf...</a><p>vs<p><a href="https:&#x2F;&#x2F;www.google.com&#x2F;search?q=%22launchctl+limit+maxfiles%22+site%3Astackoverflow.com" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.google.com&#x2F;search?q=%22launchctl+limit+maxfiles%...</a>

Globals are a nightmare. Despite this being something really common to do for developers and something that will cause a pain for a lot of early adopters of [whatever software that requires it], I see this as a great move!

As an aside, Quinn “The Eskimo!” is a legend. They have helped me on a few occasions with code signing electron apps. In the American south there is a saying “doing the lords work.” Thank goodness we have people like Quinn. Their understanding of complex system and abilities to troubleshoot are invaluable.

I am, at this exact moment, getting bodied by a ulimit problem on mac. Apparently with pacman, directories attached with bind mounts have a fixed ulimit of 64 internally and running npm install inside a mounted project explodes completely because of it. Funny that this turns up right now, even if it’s not a fix for my particular problem.

I think a security option that does the following would make sense:<p>1. exec should reduce the hard-limit to FD_SETSIZE unless it&#x27;s passed a flag<p>2. When a process calls `select` while having a hard-limit &gt; FD_SETSIZE, it gets terminated. (Strictly speaking this doesn&#x27;t prevent the memory corruption, since it happens in select&#x27;s support macros, not select itself. But I&#x27;d expect it to be good enough in practice)<p>A modern application which doesn&#x27;t use `select` should raise its own hard-limit during startup, option into the select-termination in exchange for the ability to open many files.

Only superroot (i.e., Apple) can change it.

I&#x27;ve been saying for as long as I&#x27;ve got a macbook pro that the hardware is absolutely above anything available from other vendors but macOS is crap for development. Interesting to know it actively and intentionally becomes even worse :&#x2F;

a much worse recent change is documented here:<p><a href="https:&#x2F;&#x2F;www.mothersruin.com&#x2F;software&#x2F;SuspiciousPackage&#x2F;faq.html#finder-open-with" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.mothersruin.com&#x2F;software&#x2F;SuspiciousPackage&#x2F;faq.h...</a><p>basically no experienced Mac user would ever open a .PKG package with the Installer, but rather open it with a safe inspection app (Suspicious Package, Pacifist) first, either for security inspection of the pre- &amp; post-install scripts, or to do a manual install outright to prevent the security nightmare that actually installing a package is.<p>while inspecting and&#x2F;or manually installing packages is much safer than installing packages with the installer, it is now effectively outlawed by Apple. continuing to do things in the safe way now takes a lot more time...

Just turn off SIP. SIP is for regular users who don’t know what a ulimit is, the whole point of SIP is to lock down the OS <i>as much as possible</i>.<p>If you’re a developer, you live in the Terminal, you obviously need full control over your OS.<p>edit: I appreciate the irony of being downvoted for suggesting having control over your OS on <i>Hacker</i> News, so keep it coming please. Mo’ downvotes mo’ irony.

So, who&#x27;s computer is it REALLY when you can&#x27;t make settings&#x2F;decisions about the computer you bought? When some other entity, manufacturer included, is making decisions you cant change or reverse, sounds like they retain real ownership.<p>Its high time for the FTC to start busting fraudulent rentals misrepresented as a &quot;sale&quot;.<p>(And anybody viewing the Apple ecosystem KNEW this anti-owner lockdown phone shit would eventually hit their laptop and desktop computers as well. But for some reason, the Apple fanatics are OK with this stuff. )