macOS 13.5 No Longer Allows Setting System-Wide ulimits
axeman12 (via Hacker News):
As of the newest MacOs releases (11.7.9, 12.6.8, and 13.5) I am no longer able to increase the ulimit of my computer using the strategies outlined here.
[…]
This is relevant for me as I am using Vite which is currently broken and blocks me from developing locally. It is mentioned in their troubleshooting page that Vite causes a large number of open files and how to increase the limit.
Changing a system-wide setting to work around an issue with a specific product seems rather extreme. A better option would be to change it for that process specifically. If you have access to the code, add a call to
setrlimit. If you don’t have access to the code, you could work out how the code is launched and add a wrapper, using either a shell script (and henceulimit) or a native executable (setrlimitagain).
This is in fact a bug. Good news is, there’s a workaround!
launchctl limit maxfiles 256 unlimited launchctl limit maxfiles 128000 524288
However, one commenter says this doesn’t work. What does seem to work is turning off System Integrity Protection.
Previously:
2 Comments RSS · Twitter · Mastodon
My go-to command list for having a pleasant actual superuser experience when setting up a new install of macOS:
https://gist.github.com/LeoNatan/b1cf77e1a0df2558f02631656e596408
There are still some annoyances, but overall, back to better days on the Mac.
I hate and despise what macOS has become: a pale imitation jewel aspiring to be like iPadOS. So, so sad. macOS used to be a powerful computing platform, which just so happened to be easy to use, but no more.
Latest restriction I ran into: cannot use bridged networking with virtualization.framework without special permission from Apple. You cannot even ad-hoc sign binaries or allow-list; it's simply forbidden. Workaround: run a root-owned process to talk to the net, and use sockets for IPC to the guest. But really! You may as well just use qemu. So that's what I did.
