zed
zed copied to clipboard
zed-industries
Zed fails with `Too many open files (os error 24)`
Describe the bug / provide steps to reproduce it
When opening new files, Zed sometimes fails with the error Too many open files (os error 24). This can happen from the command line by running zed [path], or in editor by attempting to open a file from the tree view or from Go to file.
Example:
> zed ~/Library/Logs/Zed/Zed.log
error opening PathWithPosition { path: "/Users/alexandrekirszenberg/Library/Logs/Zed/Zed.log", row: None, column: None }: Too many open files (os error 24)
I work on a very large repository, so I'm not surprised to hit this error as the default macOS opened file descriptors limit is 256, but it seems counter-intuitive that I'd be the first to report this issue as this is a very common setup. So maybe something else is going on.
For now, I'll try increasing this with the following:
launchctl limit maxfiles 4096 unlimited
and report back.
Environment
Zed: v0.162.0 (Zed Preview) OS: macOS 15.1.0 Memory: 32 GiB Architecture: aarch64
> ulimit -n
256
> launchctl limit maxfiles
maxfiles 256 unlimited
> sysctl kern.maxfiles
kern.maxfiles: 2147483647
If applicable, add mockups / screenshots to help explain present your vision of the feature
No response
If applicable, attach your Zed.log file to this issue.
Zed.log
I encounter the same issue (quite frequently recently). My ulimit is 2560 (I did not change that) and I encounter the issue even with only 20 files open.
I cannot tell exactly when this happens but I don't think that 20 open files should be the issue. Worth mentioning is that lsof reports more than 2560 open files, though.
The default soft-limit ulimit -Sn is 256 on macOS, but the default hard-limit ulimit -Hn is unlimited. Interestingly, my sysctl kern.maxfiles is much lower than yours (491520 vs 2147483647), I wonder if that's because I'm still on Sonoma (macOS 14.7)
On macOS I don't know of an easy way to introspect the limits for a given running process like /proc/$PID/limits on Linux.
- I'd be curious what was happening prior to it throwing that error. Could you share some log lines before this triggers?
- Can you share some details about your project: language(s), language-servers, relative size, number of files, source control (git), etc.
- Is there anything notable about your machine/setup (e.g. is this a 24-core Mac Pro cheese grater, these files on a non-APFS filesystem, etc)?
Ideally I would love an open source repo (either existing or synthetically created) that can trigger this behavior so we can understand how to reproduce it.
- I'd be curious what was happening prior to it throwing that error. Could you share some log lines before this triggers?
I unfortunately restarted Zed after this happened, but I'll send logs next time it occurs.
- Can you share some details about your project: language(s), language-servers, relative size, number of files, source control (git), etc.
This is a large monorepo using a lot of different technologies. I unfortunately can't share the repository. Our main languages are Rust, Kotlin, Swift, Starlark (Bazel), and Protobuf. We use git.
I have rust-analyzer, zed-starlark, and zed-proto running. I also have the Kotlin language server but it doesn't work (fails with LSP request timeout, seemingly unrelated.)
Here's a shorter tokei report:
===============================================================================
Language Files Lines Code Comments Blanks
===============================================================================
Swift 4051 488301 405936 17318 65047
Kotlin 1854 131877 115156 3066 13655
JSON 1346 36392 36392 0 0
TSX 235 22777 20698 198 1881
Protocol Buffers 235 19492 14498 1125 3869
YAML 36 18850 16760 12 2078
TOML 428 12587 10874 875 838
JavaScript 27 10154 8075 1236 843
TypeScript 158 9476 8301 78 1097
-------------------------------------------------------------------------------
Rust 2506 395531 341121 10536 43874
|- Markdown 844 6126 100 5414 612
(Total) 401657 341221 15950 44486
-------------------------------------------------------------------------------
Markdown 52 2512 0 1723 789
(Total) 2716 159 1763 794
-------------------------------------------------------------------------------
HTML 5 223 171 5 47
(Total) 398 315 25 58
===============================================================================
Total 11861 1173319 999523 37881 135915
===============================================================================
We have about 400 crates and around 900 additional transitive dependencies.
- Is there anything notable about your machine/setup (e.g. is this a 24-core Mac Pro cheese grater, these files on a non-APFS filesystem, etc)?
This is an M2 Max 16" MBP w/ 32GB RAM and 1TB SSD. All files are on the main APFS partition.
- I'd be curious what was happening prior to it throwing that error. Could you share some log lines before this triggers?
The log did not contain any meaningful information except the error from the title for me. This was the last time I captured some logs:
2024-11-17T15:59:54.477795+01:00 [WARN] skipping diagnostics update, no worktree found for path "/Users/ghost/.rustup/toolchains/nightly-2024-11-11-aarch64-apple-darwin/lib/rustlib/src/rust/library/core/src/num/int_macros.rs"
2024-11-17T15:59:55.995735+01:00 [ERROR] Too many open files (os error 24)
2024-11-17T15:59:58.100299+01:00 [ERROR] failed to get git blame data: Failed to blame "libs/@local/graph/migrations/src/harness.rs"
Caused by:
Failed to start git blame process: Too many open files (os error 24)
2024-11-17T16:00:28.960463+01:00 [ERROR] Too many open files (os error 24)
2024-11-17T16:00:30.451396+01:00 [ERROR] Too many open files (os error 24)
2024-11-17T16:00:47.772356+01:00 [ERROR] Too many open files (os error 24)
2024-11-17T16:01:02.716649+01:00 [ERROR] failed to get git blame data: Failed to blame "libs/@local/graph/migrations/src/harness.rs"
Caused by:
Failed to start git blame process: Too many open files (os error 24)
Maybe worth noting that this wasn't possible from Zed because Zed was not able to open any files anymore.
- Can you share some details about your project: language(s), language-servers, relative size, number of files, source control (git), etc.
The repository I'm at is quite large: https://github.com/hashintel/hash. Our main technology is Rust and Typescript, but the error also happens when only dealing with Rust code. For that I use rust-analyzer, taplo, and harper, but I guess some node LSP is running as well. (ESLint is also configured but doesn't seem to be started if I don't visit TS files).
===============================================================================
Language Files Lines Code Comments Blanks
===============================================================================
CSS 10 720 603 29 88
Dockerfile 15 588 385 34 169
Handlebars 2 86 79 0 7
HCL 92 6401 5328 390 683
HTML 5 68 65 0 3
JavaScript 16 1143 961 95 87
JSON 375 23117 23109 0 8
Jsonnet 1 4 3 1 0
Python 1 17 12 0 5
Sass 16 1494 1268 26 200
Shell 19 807 515 89 203
SQL 35 732 635 19 78
SVG 295 2933 2926 6 1
Plain Text 3 69 0 69 0
TOML 50 2146 1629 181 336
TSX 1127 123580 109359 3848 10373
TypeScript 1242 148579 119532 14083 14964
YAML 22 1619 1413 107 99
-------------------------------------------------------------------------------
Markdown 274 48890 0 39982 8908
|- ABNF 1 11 9 0 2
|- BASH 8 40 23 10 7
|- HCL 1 17 12 4 1
|- JavaScript 1 18 17 0 1
|- JSON 4 22 22 0 0
|- Ruby 1 14 8 6 0
|- Rust 3 111 87 3 21
|- Shell 6 29 29 0 0
|- TSX 1 18 14 0 4
|- TypeScript 1 21 16 2 3
|- YAML 1 24 16 8 0
(Total) 49215 253 40015 8947
-------------------------------------------------------------------------------
Rust 676 128249 110324 2619 15306
|- Markdown 254 9990 1664 5985 2341
(Total) 138239 111988 8604 17647
===============================================================================
Total 4276 491242 378146 61578 51518
===============================================================================
- Is there anything notable about your machine/setup (e.g. is this a 24-core Mac Pro cheese grater, these files on a non-APFS filesystem, etc)?
I'm on an M1 Ultra, 64 GB - Mac Studio without any external drives, only local.
I have used the SSH-remote from a MBP a few times, but not when the error happened. I'm not sure if this could be relevant.
Thank for the these details. I will see if I can reproduce with hashintel/hash locally.
M1 Ultra Mac Studio has 20 cores. I wonder if there's a magic number somewhere that works fine for 12-16 cores but falls over for 20. 🤔
Thank for the these details. I will see if I can reproduce with hashintel/hash locally.
Glad to hear, please ping me if you need any help 🙂
M1 Ultra Mac Studio has 20 cores. I wonder if there's a magic number somewhere that works fine for 12-16 cores but falls over for 20. 🤔
Hmm, that would be weird I think. But I also don't know anything about Zed's internals and if it's utilizing that many cores and if files would be opened from other threads into some thread-local storage 🤷🏻♂️
I checked out the hash repo, yarn install'd, opened dozens of files, built using cargo, jumped around via lsp navigation, etc, but was not able to trigger the Too many open files error. If you have steps which reliably reproduce for you I'm all ears.
@TimDiekmann: Worth mentioning is that lsof reports more than 2560 open files, though.
I'd be curious if there are are some number of unexpected files in that lsof output when this triggers. E.g. zed has a bunch of random open files (random large json files in the directory, but not in git, scanning .git/, etc).
Would you be willing to try and run the following script in a separate terminal window:
#!/usr/bin/env bash
set -euo pipefail
cd /tmp
mkdir -p logs
PID="$(pidof zed)"
while true
do
log_file="logs/zed_$(date +%s | awk '{print $1 % 60}')s.log"
echo -n "$log_file"
lsof -p $PID | tee "$log_file" | wc -l
sleep 1
done
This will generate a rolling set of 60 log files roughly every second with a list of the files zed has open.
So when Zed fails you can kill that script and see what was open before the file descriptors ran out.
Random correction from my earlier comment: in macOS terminal, on macOS 14.7 Sonoma, ulimit -n returns 256 but in Alacritty app or in the Zed terminal (embedded Alacritty) ulimit -n returns 2560 for me.
Sure, absolutely! Sadly, I have not a way to reliably reproduce it. Most recently, I only altered a single Rust crate without even opening many files. Maybe, I was also unlucky and Rust Analyzer is the source of the issue (at least the OP also has a very big Rust codebase, so at least that's a common denominator).
I just checked lsof -n and zed has 3147 open FDs.
Random correction from my earlier comment: in macOS terminal, on macOS 14.7 Sonoma, ulimit -n returns 256 but in Alacritty app or in the Zed terminal (embedded Alacritty) ulimit -n returns 2560 for me.
I noticed the same. Warp and Zed returns 2560, macOS' built-in terminal returns 256.
I've also been seeing this quite a bit recently with a large monorepo. I've found that running with zed --foreground . or ~/<path_to_install>/Zed\ Nightly.app/Contents/MacOS/zed . increases the maximum number of FDs used by the process, and appears to not trigger the file issue(~Needs more testing~ Been running with this for a few days, haven't ran into any lock ups yet).
I think this may be related to when the application is launched via macOS Launch Services (LSOpenFromURLSpec/open -a) versus running the executable directly. When launched through Launch Services, the app may be inheriting different file descriptor limits than when running the executable directly via std::process::Command(I'm not very familiar with Launch Services, so take this with a grain of salt)
-- edit --
Increasing the launchctl limit maxfiles limit seems prevent the issue with zed . launches having less FDs
-- end edit --
(Note I've modified the log script to output every .25 seconds)
When launched with zed ., or from spotlight
Waiting for zed process to start...
Found zed process (PID: 47054)
logs/zed_28s.log 28
logs/zed_28s.log 408
logs/zed_29s.log 494
logs/zed_29s.log 508
logs/zed_29s.log 859
logs/zed_30s.log 503
logs/zed_30s.log 488
logs/zed_31s.log 469
logs/zed_31s.log 468
logs/zed_32s.log 470
logs/zed_32s.log 479
logs/zed_32s.log 2642
logs/zed_33s.log 2626
logs/zed_33s.log 2626
When launched with zed --foreground .
❯ ./log.sh
Waiting for zed process to start...
Found zed process (PID: 48506)
logs/zed_56s.log 57
logs/zed_56s.log 504
logs/zed_57s.log 747
logs/zed_58s.log 484
logs/zed_58s.log 461
logs/zed_58s.log 472
logs/zed_59s.log 595
logs/zed_59s.log 595
logs/zed_0s.log 5512
logs/zed_0s.log 9896
logs/zed_1s.log 9737
logs/zed_2s.log 9737
I'm still seeing this error sporadically, even after increasing the limit of open files to some unreachable number.
I'm now facing this issue around once a day.
Here's an excerpt from Zed.log around the time the issue started happening:
2025-01-27T15:48:09.890204+01:00 [WARN] Language server rust-analyzer (id 4) status update: Proc-macros and/or build scripts have changed and need to be rebuilt.
2025-01-27T15:48:11.143156+01:00 [INFO] using project environment variables from CLI. PATH="..."
2025-01-27T15:48:12.686981+01:00 [ERROR] failed to get git blame data: Failed to blame "rs/platform/library/proto/macros/src/item_enum.rs"
Caused by:
Failed to start git blame process: Too many open files (os error 24)
2025-01-27T15:51:35.42089+01:00 [ERROR] Too many open files (os error 24)
2025-01-27T15:52:34.628056+01:00 [ERROR] error sending request for url (https://api.zed.dev/telemetry/events?)
Caused by:
0: client error (Connect)
1: dns error: failed to lookup address information: nodename nor servname provided, or not known
2: failed to lookup address information: nodename nor servname provided, or not known
2025-01-27T15:52:46.662113+01:00 [ERROR] Too many open files (os error 24)
2025-01-27T15:52:46.662758+01:00 [ERROR] Too many open files (os error 24)
2025-01-27T15:52:46.663325+01:00 [ERROR] Too many open files (os error 24)
2025-01-27T15:52:46.663781+01:00 [ERROR] Too many open files (os error 24)
2025-01-27T15:52:46.664157+01:00 [ERROR] Too many open files (os error 24)
After this, there are 100000 lines of Too many open files (os error 24).
This is now happening constantly for me. The symptoms are:
- Zed fails to search through all files, only searching through already opened files;
- Zed fails to save files (with no feedback);
- Zed fails to close tabs;
- Zed fails to open new files.
This has been happening an increasing amount as well. I just had one project essentially become completely bricked because I couldn't open any new files in it. Idk if this will be helpful, but I was able to "resolve" the issue by deleting the project from my recent projects list and re-opening the directory in Zed from finder anew.
I expect I'll start hitting this error again eventually, but for anyone getting stuck on this error this might help get around it for now.
Hi there! 👋 We're working to clean up our issue tracker by closing older issues that might not be relevant anymore. If you are able to reproduce this issue in the latest version of Zed, please let us know by commenting on this issue, and we will keep it open. If you can't reproduce it, feel free to close the issue yourself. Otherwise, we'll close it in 7 days. Thanks for your help!
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
I can reproduce this issue very reliably.
Every time I restart my computer, I need to run the following command:
sudo launchctl limit maxfiles 128000 524288
Otherwise launching our project in Zed will inevitably start failing with "Too many open files" after a few minutes.
I'm seeing this happen repeatedly in a small repo containing just 295 files. lsof shows that zed has the same files/directories open hundreds of times under different file descriptors:
$ lsof -n | tr -s ' ' | cut -d ' ' -f 1,9 | grep '^zed /' | sort | uniq -c | sort -nr | head
271 zed /Users/ph
271 zed /Users
270 zed /System/Volumes/Data
270 zed /System/Volumes
270 zed /System
254 zed /Users/ph/.git.d/excludes
254 zed /Users/ph/.git.d
62 zed /Users/ph/Library/Application
26 zed /Users/ph/.config/zed
17 zed /Users/ph/.config
A "workspace: reload" command fixes the issue temporarily. This started today when I updated to Zed 0.206.6 from one of the versions that had broken auto-updating.
I'm trying to isolate what actions caused this for me but I can't reproduce it yet.
This wasn't the bug that I ran into but I did notice that opening then closing a project containing a single file seems to leak at least 20 file descriptors: lsof shows:
- 184 files after launching zed
- 224 after opening a project
- 205 after closing it
- 267 after opening it again
- 245 after closing it again
This was just clicking "File" then "Open Recent" then the project name, then closing the window, I didn't interact with the project in any way. The difference between the 184 files and 245 files is:
11 > zed /Users/ph/.config/zed
6 > zed /Users/ph/Library/Application Support/Zed/db/0-stable/db.sqlite-wal
6 > zed /Users/ph/Library/Application Support/Zed/db/0-stable/db.sqlite
5 > zed /Users/ph/.config
5 > zed /Users/ph
5 > zed /Users
5 > zed /System/Volumes/Data
5 > zed /System/Volumes
5 > zed /System
1 > zed /System/Volumes/Preboot/Cryptexes/App/System/Applications/Safari.app/Contents/Resources/en.lproj/ServicesMenu.strings
1 > zed /System/Library/PrivateFrameworks/Shortcut.framework/Versions/A/Resources/SearchManager2.loctable
1 > zed /System/Library/PrivateFrameworks/Shortcut.framework/Versions/A/Resources/Localizable.loctable
1 > zed /System/Library/PrivateFrameworks/SFSymbols.framework/Versions/A/Resources/CoreGlyphsPrivate.bundle/Contents/Resources/Assets.car
1 > zed /System/Library/Frameworks/AppKit.framework/Versions/C/Resources/Services.loctable
1 > zed /System/Library/Frameworks/AppKit.framework/Versions/C/Resources/Menus.loctable
1 > zed /System/Library/Frameworks/AppKit.framework/Versions/C/Resources/Accessibility.loctable
1 > zed /System/Library/Fonts/LucidaGrande.ttc
1 > zed /System/Library/Fonts/Keyboard.ttf
Seeing the same thing as @paulhammond. I asked Codex for a fix and it believes this may be due to symlinks. Looking at open files, if I have the following project hierarchy:
a/
b/
c/
d/
Then Zed will separately watch:
a/b/c/
a/b/
a/
a/d
a/
Codex proposed this fix, which I'm not familiar enough with the current behavior to review properly.
I mentioned this started happening after updating to Zed 0.206.6, but I've just noticed that update included #37657 so the new "os error 24" message is just a better message than the old "Unsupported File Type" I would see occasionally (similar to #37777 and #37648). So I don't think this is a new bug.
