-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"too many open files" since update to v1.43.0 #2355
Comments
Hello, if someone can provide a way to reproduce the problem, it could help in the diagnosis. Maybe @sebastien-rosset can take a look. Note: It can be related to the performance problem that I detected #2041 (comment) |
You are running on mac. To troubleshoot, you can obtain the current limit of file descriptors:
You might be able to temporarily work around the problem by increasing the limits. For a deeper analysis, we would need to analyze the files that are opened by golangci-lint when running the test with 1.42.1 vs running with 1.43.0 Maximum limits:
Ref: too many open files |
$ launchctl limit maxfiles
maxfiles 256 unlimited
$ sysctl kern.maxfiles
kern.maxfiles: 49152
$ sysctl kern.maxfilesperproc
kern.maxfilesperproc: 24576 And all soft and hard limits via ulimit: $ ulimit -aS
-t: cpu time (seconds) unlimited
-f: file size (blocks) unlimited
-d: data seg size (kbytes) unlimited
-s: stack size (kbytes) 8192
-c: core file size (blocks) 0
-v: address space (kbytes) unlimited
-l: locked-in-memory size (kbytes) unlimited
-u: processes 2784
-n: file descriptors 256
$ ulimit -aH
-t: cpu time (seconds) unlimited
-f: file size (blocks) unlimited
-d: data seg size (kbytes) unlimited
-s: stack size (kbytes) 65532
-c: core file size (blocks) unlimited
-v: address space (kbytes) unlimited
-l: locked-in-memory size (kbytes) unlimited
-u: processes 2784
-n: file descriptors unlimited Using e.g. I can also reproduce those errors when running against github.com/golang/go/src for example:
|
Since I wasn't able to reproduce this issue lately and since this issue is currently not active, I'm going to close it for now. |
I was just able to reproduce the issue and I found a fix 🤦♂️ If you ended up here via a search: What helped me was increasing the soft limit for file descriptors by setting |
This isn't a "fix", this is a workaround. The real fix is to implement control for amount of simultaneously open files by executed linters. So, please, reopen the issue. Since update from v1.42.1 to v1.45.2 I often get error from gci linter like this:
My project has 376 .go files and I use default limit for max open files (1024). There is |
Just to confirm I started having the issue too and the workaround, well... works around it. Seems there is not really a leak, just a very high number of descriptors, which is somehow to be expected when running concurrent code accessing files. |
Welcome
Description of the problem
With v1.42.1 everything was fine, however since the update to v1.43.0 I often get some sort of "too many open file" errors when running it on a rather big (closed-source) project, either in combination with "failed to save|get data to low-level cache", linters not being able to run like gci in the example below, or errors like
could not import <...> (<...>.go:1: too many open files) (typecheck)
.The errors only occur when gocritic is enabled and stand-alone gocritic works just fine. The likelihood of such errors greatly increases when I run gociritic together with some other linters. My best guess is, that this is some resource leak connected with gocritic.
Version of golangci-lint
Configuration file
Go environment
Verbose output of running
Code example or link to a public repository
none
The text was updated successfully, but these errors were encountered: