What is the exact command that you run that prints that error message?

Commands I ran that produce same error:

go run .
go run main.go

I ran go mod tidy earlier and it completely messed up everything and failed because it tried to search my entire filesystem. Not sure if causal relationship is there, but that context might help.

I also tried uninstalling and reinstalling go and my terminal but that didn’t help.

What does go run -x print?

/usr/local/go/src/vendor/golang.org/x/text/unicode/bidi/core.go:9:2: open /usr/local/go/src/log/example_test.go: too many open files in system

Why is go trying to open these files?

golang.org/x/text/unicode/bidi imports the log package.

Compiling the log package itself shouldnt require opening example_test.go, but as of Go 1.19 the go` command indexes package information and uses that instead of reopening files for each build. That is supposed to happen only once per build, but of course if that fails the index won't be written to the cache.

But, that seems like something of a red herring — if the error is too many open files in system, what else on your system is holding files open? (If it were just the go command, the error would presumably be too many open files instead.)

A good starting point for that investigation might be to run lsof and see if you spot a pattern.

I have about 8007 open files in my system on fresh reboot and closing my applications. I set a soft limit for 10240, but there's a hard limit of unlimited. Even if I set the soft limit to unlimited, go still throws the same error.

ulimit -aS
-t: cpu time (seconds)              unlimited
-f: file size (blocks)              unlimited
-d: data seg size (kbytes)          unlimited
-s: stack size (kbytes)             8176
-c: core file size (blocks)         0
-v: address space (kbytes)          unlimited
-l: locked-in-memory size (kbytes)  unlimited
-u: processes                       1333
-n: file descriptors                10240

I also tried changing the maxfile limit for MacOS following these instructions, which changes the default from 256 to 64000 when you open a fresh terminal (instead of having to manually set it per session), but that had no effect:

ulimit -a
-t: cpu time (seconds)              unlimited
-f: file size (blocks)              unlimited
-d: data seg size (kbytes)          unlimited
-s: stack size (kbytes)             8176
-c: core file size (blocks)         0
-v: address space (kbytes)          unlimited
-l: locked-in-memory size (kbytes)  unlimited
-u: processes                       2000
-n: file descriptors                64000

So I think I addressed the "too many open files in system" issue, but Go is still complaining. I suspect this is some MacOS-specific ARM64 weirdness and may just be unique to my machine.

FWIW, based on https://superuser.com/questions/433746/is-there-a-fix-for-the-too-many-open-files-in-system-error-on-os-x-10-7-1 I checked a couple of the builders operated by the Go project and found:

darwin-amd64-13-0:

$ lsof | wc -l
    3311
$ sysctl kern.maxfiles
kern.maxfiles: 30720
$ sysctl kern.maxfilesperproc
kern.maxfilesperproc: 10240

darwin-arm64-12:

$ lsof | wc -l
    3643
$ sysctl kern.maxfiles
kern.maxfiles: 122880
$ sysctl kern.maxfilesperproc
kern.maxfilesperproc: 61440

Even on the amd64 builder with a maxfilesperproc limit of only 10240, that seems like plenty of headroom. I would be surprised if any of those limits were adjusted when the builder images were created. (There aren't any such steps listed in https://cs.opensource.google/go/x/build/+/master:env/darwin/setup-notes.md.)

Perhaps you have some kind of third-party service installed that is holding a lot of files open?

Yeah, i’m going to do a clean install and see if I can reproduce.

I was running out of file descriptors on Mac OS every few days a few months ago. It started around the time I installed Tailscale's Golink program, and it seemed to be related to that because, it seemed to stop when I stopped running it, and since I upgraded Golink a few weeks ago, the problem hasn't recurred. I'm still unsure what the root cause was though, maybe that's a coincidence. I've also had instability with my Time Machine backups.

I erased all contents and settings on my Mac and re-installed go and was able to run it. There's still about ~6265 open files by default on Ventura 13.1, but go no longer complains. I guess I'll be careful about what third-party software I install next time.

And thanks to everyone for responding so quickly and jumping on this. Really impressed by the community and support.