PackerUpdate UI freezes in iTerm2 on MacOS

[gwerbin]

PackerUpdate and PackerSync cause the Packer window to freeze when running within iTerm 2 on MacOS. It's unclear if the operation behind the UI completed successfully and the UI just crashed/froze, or if the underlying operation also crashed/froze. The only warning/error is a message that redrawtime had been exceeded. I tried setting redrawtime to something really high, like 20000, but I still get the error (and it triggers in less than 20 seconds).

When running the same update command in Neovim-Qt on the same machine, it works fine and the Packer window says "Everything up to date", although it takes several seconds to render any text in the Packer window at all. I do not get the redrawtime warning under Neovim-Qt.

The frozen update screen looks something like this:

           packer.nvim - updating 70 / 143 plugins           
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 
 ⟳ co1ncidence/sunset.vim: checking current commit...
 ⟳ zefei/simple-dark: checking current commit...
 ⟳ nvim-telescope/telescope-dap.nvim: checking current commit...
 ⟳ vim-scripts/pyte: checking current commit...
 ⟳ tomtom/tcomment_vim: checking current commit...
 ⟳ vim-scripts/proton: checking current commit...
 ⟳ wellle/targets.vim: checking current commit...
 ⟳ nvim-lua/popup.nvim: checking current commit...
 ⟳ vim-airline/vim-airline-themes: checking current commit...
 ⟳ nvim-telescope/telescope.nvim: checking current commit...
 ⟳ nvim-lua/plenary.nvim: checking current commit...
 ⟳ vim-airline/vim-airline: checking current commit...
 ⟳ axvr/photon.vim: checking current commit...
 ⟳ vim-scripts/phd: checking current commit...
 ⟳ lifepillar/pgsql.vim: checking current commit...
 ⟳ drewtempelmeyer/palenight.vim: checking current commit...
 ⟳ wbthomason/packer.nvim: checking current commit...
 ⟳ Th3Whit3Wolf/onebuddy: checking current commit...
 ⟳ Th3Whit3Wolf/one-nvim: checking current commit...
 ⟳ mhartington/oceanic-next: checking current commit...
 ⟳ nvim-treesitter/nvim-treesitter-textobjects: checking current commit...
 ⟳ nvim-treesitter/nvim-treesitter: checking current commit...
 ⟳ neovim/nvim-lspconfig: checking current commit...
 ⟳ theHamsta/nvim-dap-virtual-text: checking current commit...
 ⟳ mfussenegger/nvim-dap-python: checking current commit...
 ⟳ norcalli/nvim-colorizer.lua: checking current commit...
 ⟳ arcticicestudio/nord-vim: checking current commit...
 ⟳ zah/nim.vim: checking current commit...
 ⟳ preservim/nerdtree: checking current commit...
 ⟳ kassio/neoterm: checking current commit...
 ⟳ adelarsq/neoline.vim: checking current commit...
 ⟳ co1ncidence/mountaineer.vim: checking current commit...
 ⟳ co1ncidence/monokai-pro.vim: checking current commit...
 ⟳ wfxr/minimap.vim: checking current commit...
 ⟳ glepnir/lspsaga.nvim: checking current commit...
 ⟳ itchyny/lightline.vim: checking current commit...
 ⟳ JuliaEditorSupport/julia-vim: checking current commit...
 ⟳ vito-c/jq.vim: checking current commit...
 ⟳ nanotech/jellybeans.vim: checking current commit...
 ⟳ co1ncidence/javacafe.vim: checking current commit...
 ⟳ co1ncidence/itai.vim: checking current commit...
 ⟳ hkupty/iron.nvim: checking current commit...
 ⟳ Yggdroot/indentLine: checking current commit...
 ⟳ cocopon/iceberg.vim: checking current commit...
 ⟳ othree/html5.vim: checking current commit...
 ⟳ mfussenegger/nvim-dap: checking current commit...
 ⟳ YorickPeterse/happy_hacking.vim: checking current commit...
 ⟳ NieTiger/halcyon-neovim: checking current commit...
 ⟳ co1ncidence/gunmetal.vim: checking current commit...
 ⟳ sjl/gundo.vim: checking current commit...
 ⟳ npxbr/glow.nvim: checking current commit...
 ⟳ rhysd/git-messenger.vim: checking current commit...
 ⟳ jaredgorski/fogbell.vim: checking current commit...
 ⟳ bakpakin/fennel.vim: checking current commit...
 ⟳ editorconfig/editorconfig-vim: checking current commit...
 ⟳ dracula/vim: checking current commit...
 ⟳ jsit/disco.vim: checking current commit...
 ⟳ Shougo/denite.nvim: checking current commit...
 ⟳ nightsense/cosmic_latte: checking current commit...
 ⟳ nvim-lua/completion-nvim: checking current commit...
 ⟳ tjdevries/colorbuddy.vim: checking current commit...
 ⟳ ms-jpq/chadtree: checking current commit...
 ⟳ co1ncidence/bliss: checking current commit...
 ⟳ chriskempson/base16-vim: checking current commit...
 ⟳ ayu-theme/ayu-vim: checking current commit...
 ⟳ zacanger/angr.vim: checking current commit...
 ⟳ jdsimcoe/abstract.vim: checking current commit...
 ⟳ tmhedberg/SimpylFold: checking current commit...
 ⟳ kreskij/Repeatable.vim: checking current commit...
 ✓ vim-scripts/yowish: already up to date
 ✓ chrisbra/NrrwRgn: already up to date
 ✓ HerringtonDarkholme/yats.vim: already up to date
 ✓ overcache/NeoSolarized: already up to date
 ✓ othree/yajs.vim: already up to date
 ✓ Konfekt/FastFold: already up to date
 ✓ vlime/vlime: already up to date
 ✓ romainl/Apprentice: already up to date
 ✓ wellle/visual-split.vim: already up to date
 ✓ liuchengxu/vista.vim: already up to date
 ✓ lervag/vimtex: already up to date
 ✓ nightsense/vimspectr: already up to date
 ✓ chaoren/vim-wordmotion: already up to date
 ✓ wesQ3/vim-windowswap: already up to date
 ✓ tpope/vim-unimpaired: already up to date
 ✓ cespare/vim-toml: already up to date
 ✓ mswift42/vim-themes: already up to date
 ✓ kana/vim-textobj-user: already up to date
 ✓ kana/vim-textobj-indent: already up to date
 ✓ tpope/vim-surround: already up to date
 ✓ dstein64/vim-startuptime: already up to date
 ✓ mhinz/vim-startify: already up to date
 ✓ christoomey/vim-sort-motion: already up to date
 ✓ justinmk/vim-sneak: already up to date
 ✓ voldikss/vim-skylight: already up to date
 ✓ mhinz/vim-signify: already up to date
 ✓ kshenoy/vim-signature: already up to date
 ✓ tpope/vim-scriptease: already up to date
 ✓ tpope/vim-repeat: already up to date
 ✓ dhruvasagar/vim-prosession: already up to date
 ✓ junegunn/vim-peekaboo: already up to date
 ✓ rakr/vim-one: already up to date
 ✓ tpope/vim-obsession: already up to date
 ✓ noahfrederick/vim-noctu: already up to date
 ✓ LnL7/vim-nix: already up to date
 ✓ haya14busa/vim-metarepeat: already up to date
 ✓ jonathanfilip/vim-lucius: already up to date
 ✓ embear/vim-localvimrc: already up to date
 ✓ tommcdo/vim-lion: already up to date
 ✓ noahfrederick/vim-hemisu: already up to date
 ✓ jparise/vim-graphql: already up to date
 ✓ airblade/vim-gitgutter: already up to date
 ✓ tpope/vim-fugitive: already up to date
 ✓ voldikss/vim-floaterm: already up to date
 ✓ tommcdo/vim-exchange: already up to date
 ✓ tpope/vim-eunuch: already up to date
 ✓ Olical/vim-enmasse: already up to date
 ✓ elixir-editors/vim-elixir: already up to date
 ✓ easymotion/vim-easymotion: already up to date
 ✓ jeffkreeftmeijer/vim-dim: already up to date
 ✓ ap/vim-css-color: already up to date
 ✓ rbong/vim-crystalline: already up to date
 ✓ altercation/vim-colors-solarized: already up to date
 ✓ reedes/vim-colors-pencil: already up to date
 ✓ habamax/vim-colors-defminus: already up to date
 ✓ gyim/vim-boxdraw: already up to date
 ✓ benknoble/vim-auto-origami: already up to date
 ✓ Nequo/vim-allomancer: already up to date
 ✓ preservim/tagbar: already up to date
 ✓ kovetskiy/sxhkd-vim: already up to date
 ✓ inkarkat/vim-ingo-library: already up to date
 ✓ inkarkat/vim-AdvancedDiffOptions: already up to date
 ✓ srcery-colors/srcery-vim: already up to date
 ✓ chrisbra/unicode.vim: already up to date
 ✓ glepnir/spaceline.vim: already up to date
 ✓ mbbill/undotree: already up to date
 ✓ Th3Whit3Wolf/space-nvim: already up to date
 ✓ logico/typewriter: already up to date
 ✓ xero/sourcerer.vim: already up to date
 ✓ markonm/traces.vim: already up to date
 ✓ vim-scripts/sorcerer: already up to date
 ✓ jacoborus/tender.vim: already up to date
 ✓ kovisoft/slimv: already up to date

[wbthomason]

Thanks for the report! Unfortunately, my ability to debug this one is next to nil - I don't have access to a MacOS environment.

Did this start recently? In particular, had you updated packer or neovim shortly before first noticing this issue?

I'm almost wondering if this is an upstream bug. It sounds like it could be a problem with Neovim's rendering.

The redrawtime warning could point to an issue with syntax highlighting being inappropriately applied in the packer window, but that would seemingly trigger on other platforms too.

[akinsho]

Not sure if iTerm2 is important here but I run packer on macOS and Linux and haven't been having any issues running PackerSync or PackerUpdate. My build is NVIM v0.5.0-dev+nightly-434-gc95e797b83 i.e. from last Thursday/Friday.

[gwerbin]

Thanks for the report! Unfortunately, my ability to debug this one is next to nil - I don't have access to a MacOS environment.

Did this start recently? In particular, had you updated packer or neovim shortly before first noticing this issue?

I'm almost wondering if this is an upstream bug. It sounds like it could be a problem with Neovim's rendering.

The redrawtime warning could point to an issue with syntax highlighting being inappropriately applied in the packer window, but that would seemingly trigger on other platforms too.

This has been going since way back when I first reported the issue about Packer freezing during the Git password prompt. I've been meaning to report it for a while.

My current version info:

• Neovim v0.5.0-dev+1000-g84d08358b, built with brew install --HEAD neovim
• Packer commit c5b7f23e0b406767c1918d6888962fdb97f951e8
• iTerm 3.4.3 with TERM=xterm-256color

On my Linux machine, I was not able to reproduce this in Urxvt:

• Neovim v0.5.0-dev+e0a4399
• Packer commit c5b7f23e0b406767c1918d6888962fdb97f951e8
• rxvt-unicode 9.22 with TERM=rxvt-unicode

But I was able to reproduce on the Mac in Terminal.app.

I have also been having trouble lately with Terminfo not working right on my Mac. So I actually have a suspicion that the problem ultimately lies with whatever is wrong with my Terminfo database, and not iTerm specifically. Which would explain why it fails in all Mac terminals, succeeds in a Mac GUI, and succeeds in all Linux terminals & GUIs.

This might be a non-issue and/or an upstream issue. Need to investigate more when I have time.

Edit: Terminfo issue turned out to be local to my shell init script. Frozen Packer window issue persists in Terminal.app and iTerm2.

[mherna]

@gwerbin I'm having the same issue on my mac, please let me know if you find a solution

[wbthomason]

@mherna: Also with iTerm2/Terminal.app? @akinsho, what terminal emulator do you use?

Have you had this problem with PackerInstall, or just update/sync?

Have you had this/similar problems with other Neovim plugins, e.g. telescope?

Finally, could you please update packer and post the contents of ~/.cache/nvim/packer.nvim.log after running an update/sync? I recently added more debug logging which should help us determine if this is a task hanging and blocking everything or the display not redrawing for some reason.

[akinsho]

I use kitty exclusively on my mac @wbthomason

[wbthomason]

Thanks - for reference, I also exclusively use kitty (on Linux) and cannot reproduce this.

[gegoune]

I am gonna risk being funny here but a good while ago I though I experienced something like that. It was all due to window being pretty small (in multiple planes) and for some reason packer/nvim was waiting for me to hit enter after showing some message, if I remember correctly it was about rplugin file being created/updated. It could be something like this perhaps?

[wbthomason]

Ah - Neovim (or Vim) will prompt for Enter by default if a certain number of message lines get printed all at once, which can happen after running UpdateRemotePlugins. Maybe that's happening here? I would be a bit surprised, though.

[gwerbin]

During one of these window freezes, I don't see any prompt appear, and I don't see output in :messages other than the 'redrawtime' exceeded one.

Also, the window is not really freezing. I can still interact with Nvim by moving the cursor, typing Ex commands, etc. But the information in the Packer window gets stuck part-way through updating.

It happens no matter how big the terminal window is.

I still wonder if this is an upstream Nvim issue relating to how control codes are processed by both of these Mac terminals. What mechanism does Packer use to redraw the window?

[wbthomason]

Packer uses extmarks to track which lines correspond to which tasks, then sets modifiable=true for the display buffer, uses nvim_buf_set_lines to set the contents of the line, and sets modifiable=false again.

As far as I know, this is fairly standard? Looking at vim-packager, for example, it seems to take this general approach (though it does refresh only on a timer, whereas packer refreshes whenever there's new data). Perhaps Neovim cannot keep up with rapid updates on iTerm2, for some reason?

[mherna]

@wbthomason yes, the issue also happens in terminal.app. telescope.nvim works well, and correct it happens when running PackerSync and PackerUpdate; PackerInstall works fine.

Here are the logs. It appears to get stuck waiting for plugin info is not ready yet.

[INFO  Fri Feb 12 12:37:24 2021] .../site/pack/packer/start/packer.nvim/lua/packer/clean.lua:78: Already clean!
[ERROR Fri Feb 12 12:37:25 2021] .../site/pack/packer/start/packer.nvim/lua/packer/async.lua:17: Error in coroutine: ...ite/pack/packer/start/packer.nvim/lua/packer/install.lua:26: attempt to call upvalue 'fmt' (a nil value)
[ERROR Fri Feb 12 12:37:25 2021] .../site/pack/packer/start/packer.nvim/lua/packer/async.lua:17: Error in coroutine: ...ite/pack/packer/start/packer.nvim/lua/packer/install.lua:26: attempt to call upvalue 'fmt' (a nil value)
[DEBUG Fri Feb 12 12:37:26 2021] ...site/pack/packer/start/packer.nvim/lua/packer/update.lua:88: Failed to update AndrewRadev/sideways.vim: {
  data = {
    data = {
      exit_code = 1,
      signal = 0
    },
    msg = "Error pulling updates for AndrewRadev/sideways.vim: Your configuration specifies to merge with the ref 'refs/heads/master'\nfrom the remote, but no such ref was fetched."
  },
  msg = "Error checking updated commit for AndrewRadev/sideways.vim: 19c5a21"
}
[INFO  Fri Feb 12 12:37:35 2021] ...ite/pack/packer/start/packer.nvim/lua/packer/display.lua:381: Operations are still running; plugin info is not ready yet
[INFO  Fri Feb 12 12:37:40 2021] ...ite/pack/packer/start/packer.nvim/lua/packer/display.lua:381: Operations are still running; plugin info is not ready yet
[INFO  Fri Feb 12 12:37:42 2021] ...ite/pack/packer/start/packer.nvim/lua/packer/display.lua:381: Operations are still running; plugin info is not ready yet
[INFO  Fri Feb 12 12:37:43 2021] ...ite/pack/packer/start/packer.nvim/lua/packer/display.lua:381: Operations are still running; plugin info is not ready yet
[INFO  Fri Feb 12 12:37:54 2021] ...ite/pack/packer/start/packer.nvim/lua/packer/display.lua:381: Operations are still running; plugin info is not ready yet
[INFO  Fri Feb 12 12:37:59 2021] ...ite/pack/packer/start/packer.nvim/lua/packer/display.lua:381: Operations are still running; plugin info is not ready yet

[mherna]

@wbthomason if running PackerUpdate it in any other terminal emulator may help solve the issue please let me know and I will try it.

[gwerbin]

How did you get those logs? I'd like to check mine as well.

I think I once had that "no such ref" problem in a plugin, and fixing it resolved the issue for a short while. Maybe there's something going wrong when Packer clones certain plugins from Github, causing it to freeze?

[mherna]

@gwerbin nvim .cache/nvim/packer.nvim.log

[mherna]

If it helps... I use @tjdevries neovim configuration

[gwerbin]

Unfortunately I don't see any such output in my case. I just see the "already clean!" message.

Would it help to post my compiled packer script?

[wbthomason]

@gwerbin: I recently added more debug logging; if you're not on the latest version of packer or haven't encountered this issue since you last updated packer, you may not have any useful output.

@mherna: That output actually points more toward a problem with git - the "info is not ready yet" message gets printed when you press on the packer display before all operations have finished.

It seems that either (as #200 might also imply) the git hanging issue is not as fixed as we thought in #91. I'm wondering if there's something different with the git-relevant environment variables (or your particular git config) on macOS that causes this?

It is also possible that there's an issue in the async module which causes the set of jobs to hang if one fails in this way, but I think we would see that more broadly. Still, it could be the cause.

[mherna]

@wbthomason I was pressing the return key; that's why those messages got added to the logs.

The git version I was running was git version 2.24.3 (Apple Git-128) I used brew to install a newer version of git, and now I'm running git version 2.30.1, but the issue persists. I also checked my network packets, and once the packer window "freezes," no more packets are being sent or received.

I also reviewed my environment variables, and I have no variables related to git, which could affect Packer.nvim. Besides, I removed those plugins that were not found. My new :PackerUpdate logs are:

As you say, it is probably related to #200

[INFO  Fri Feb 12 15:39:10 2021] .../site/pack/packer/start/packer.nvim/lua/packer/clean.lua:78: Already clean!
[DEBUG Fri Feb 12 15:39:12 2021] ...site/pack/packer/start/packer.nvim/lua/packer/update.lua:80: Updated pwntester/octo.nvim: {
  err = {},
  messages = { "a91c61a Merge branch 'master' of github.com:pwntester/octo.nvim (47 seconds ago)", "ab97242 fix #86 (2 minutes ago)" },
  output = { "remote: Enumerating objects: 31, done.        \nremote: Counting objects:   3% (1/31)        \rremote: Counting objects:   6% (2/31)        \rremote: Counting objects:   9% (3/31)        \rremote: Counting objects:  12% (4/31)        \rremote: Counting objects:  16% (5/31)        \rremote: Counting objects:  19% (6/31)        \rremote: Counting objects:  22% (7/31)        \rremote: Counting objects:  25% (8/31)        \rremote: Counting objects:  29% (9/31)        \rremote: Counting objects:  32% (10/31)        \rremote: Counting objects:  35% (11/31)        \rremote: Counting objects:  38% (12/31)        \rremote: Counting objects:  41% (13/31)        \rremote: Counting objects:  45% (14/31)        \rremote: Counting objects:  48% (15/31)        \rremote: Counting objects:  51% (16/31)        \rremote: Counting objects:  54% (17/31)        \rremote: Counting objects:  58% (18/31)        \rremote: Counting objects:  61% (19/31)        \rremote: Counting objects:  64% (20/31)        \rremote: Counting objects:  67% (21/31)        \rremote: Counting objects:  70% (22/31)        \rremote: Counting objects:  74% (23/31)        \rremote: Counting objects:  77% (24/31)        \rremote: Counting objects:  80% (25/31)        \rremote: Counting objects:  83% (26/31)        \rremote: Counting objects:  87% (27/31)        \rremote: Counting objects:  90% (28/31)        \rremote: Counting objects:  93% (29/31)        \rremote: Counting objects:  96% (30/31)        \rremote: Counting objects: 100% (31/31)        \rremote: Counting objects: 100% (31/31), done.        \nremote: Compressing objects:  25% (1/4)        \rremote: Compressing objects:  50% (2/4)        \rremote: Compressing objects:  75% (3/4)        \rremote: Compressing objects: 100% (4/4)        \rremote: Compressing objects: 100% (4/4), done.        \nremote: Total 10 (delta 6), reused 10 (delta 6), pack-reused 0        \nFrom https://github.com/pwntester/octo.nvim\n   e8fb856..a91c61a  master     -> origin/master", "Updating e8fb856..a91c61a\nFast-forward\n lua/octo/reviews.lua | 4 ++++\n 1 file changed, 4 insertions(+)" },
  revs = { "e8fb856", "a91c61a" }
}

[akinsho]

Okay so turn of events but I'm now seeing this issue on my mac as well using kitty it doesn't always happen , but sometimes running PackerSync stalls and never completes. I see errors relating to number of opened files allowed similar to #149. I tried re-running the command a few times and I think when you close the window when it hangs it doesn't kill any running jobs so then hitting the command again spins up even more jobs which triggers #149.

[akinsho]

I just experimented with the solution from #149 i.e. I ran ulimit -S -n 200048 to increase the number of allowed files that can be opened and that seems to allow the command to run without issues. @mherna can you see if running that command in your shell then re-opening neovim and running packer update helps at all?

[wbthomason]

Maybe there should be a default job limit, rather than defaulting to starting everything at once? @mherna @akinsho, roughly how many plugins do you have?

[mherna]

I have 130 plugins @wbthomason, @akinsho is correct setting ulimit -S -n 200048 worked wonders now PackerUpdate ran successfully.

[akinsho]

I have about 70 on my mac, I'm curious how many jobs packer is running to actually hit this limit in the first place. The things I found on this indicate macOS is a little stingy but still seems like the default is in the thousands so wondering how packer could hit this unless its running like 10-20+ jobs per plugin?

EDIT: also wondering what happens to all the jobs if you press q before they finish I'm assuming they try and continue in the back ground but this won't stop you from just running the command again?

[wbthomason]

@akinsho: Right, I too am surprised that packer would be running this many simultaneous jobs - each plugin should have at most one job running at a time. If you press q before they finish, the currently running jobs may continue but no new top-level jobs should start (the async pool will prevent new tasks from starting).

Does this ever happen in a fresh terminal, i.e. a shell process with no chance of previously opened files that are lingering, etc.?

[akinsho]

Not sure @wbthomason I use tmux and have windows and panes up for ages but do restart my Mac now and again. Not sure if it'd be different in a new shell can try and see when next I get a chance.

[cehoffman]

The file limit does seem to be the issue. I was experiencing this as well and I have 82 plugins. Setting the higher limit with ulimit -S -n 200048 lets the PackerUpdate run to completion. I'm in a fairly typical environment as well with iTerm2 and several tmux panes. Setting it so high isn't required. My work computer isn't allowing that high a limit but 40000 works to fix the issue.

[akinsho]

@wbthomason I've tried a few times and this seems to eventually creep up, this article is quite a useful explainer but the TLDR is that it's a per application limit i.e. all of nvim's files are included in this not just packer but the limit is still 10,000 +. by default If it helps I've never experienced this issue prior to using packer so I don't think this is some other errant code in some part of nvim.

I wonder if some tidying up of resources is required between backer runs like job:close or something some of the luv jobs pure guesswork on my end. I can just add the command to my zshrc but as the article points out the limit is quite high and its indicative of a bug for it to be this high. I think the fact that it worsens the longer the shell/nvim is open for seems to me to indicate that the count is only increasing.

I wonder if the files could be visualised and I could use that to track the count over time

[wbthomason]

Yeah, it seems like there is some sort of resource leak. I don't know a way to visualize this, unfortunately, or have any idea why it just happens on macOS (I haven't been able to reproduce it on Linux, even with setting my per process file limit unusually low).

The only places packer opens files are the compile module and the jobs module. I doubt the compile module causes this; it only ever opens a single file per run, and cleanly closes it.

The jobs module could be causing a leak if some jobs aren't having their stdio fd's cleaned up correctly (though there's logic to do this).

[akinsho]

The jobs module could be causing a leak if some jobs aren't having their stdio fd's cleaned up correctly (though there's logic to do this).

Do you know what line this is happening at, I can log things out on my mac and confirm that they are being closed properly

[wbthomason]

I did a little poking around on my system with this (Linux, though), looking at /proc/{PID}/fd for my Neovim process - there's no change in the number of fds open before or after running PackerSync (across running ~10 trials). This might be intermittent or maybe macOS dependent? Or it could be something that contributes to the file limit but isn't listed under fd...

Pipes are closed in the case of timeout here https://github.com/wbthomason/packer.nvim/blob/6d7be3232ed0dcbbd040bf92ba70b997fe4fd840/lua/packer/jobs.lua#L81

And in normal use here https://github.com/wbthomason/packer.nvim/blob/6d7be3232ed0dcbbd040bf92ba70b997fe4fd840/lua/packer/jobs.lua#L24-L25

[akinsho]

So it turns out this is fairly easy to check on macOS using this SO answer I had a look on my system and there seemed to be fairly few open files but I ran the ulimit command a few days ago and haven't restarted my shell without it since. So if someone still experiencing it wants to try, it's just clicking in the activity monitor GUI.

Not sure if it's related possibly not but I also found https://github.com/neovim/neovim/pull/14197 so not sure if it's possible that that was also contributing. Again not sure just seemed related given the similar error.

[mherna]

I ran the command and checked the system monitor opened files and ports tabs. I believe the first 32 files are neovim core related, the others are created when you start running PackerSync, I also see some nones that might be the errors making PackerSync fail eg.50->(none). However, I don't think the output is helpful to convey why Packer is failing, but if any other tests can help let me know and I'll run them 😄.

Output:

cwd
/Users/xxxxxx
txt
/opt/homebrew/Cellar/neovim/HEAD-0ab88c2_1/bin/nvim
txt
/opt/homebrew/Cellar/gettext/0.21/lib/libintl.8.dylib
txt
/opt/homebrew/Cellar/libuv/1.41.0/lib/libuv.1.dylib
txt
/opt/homebrew/Cellar/msgpack/3.3.0/lib/libmsgpackc.2.0.0.dylib
txt
/opt/homebrew/Cellar/libvterm/0.1.4/lib/libvterm.0.dylib
txt
/opt/homebrew/Cellar/libtermkey/0.22/lib/libtermkey.1.dylib
txt
/opt/homebrew/Cellar/unibilium/2.1.0/lib/libunibilium.4.dylib
txt
/opt/homebrew/Cellar/tree-sitter/0.19.3/lib/libtree-sitter.0.0.dylib
txt
/opt/homebrew/Cellar/luajit-openresty/20201229_1/lib/libluajit-5.1.2.1.0.dylib
txt
/usr/lib/dyld
0
/dev/ttys000
1
/dev/ttys000
2
/dev/ttys000
3
count=25, state=0x8
4
->0x1d163460ca902c3b
5
->0x236ac018a5e225eb
6
->0x19f82d1d99663380
7
->0x1d1a1456ff841c88
8
->0xa8f091509731345
9
->0x4951aed88e4e53b2
10
count=0, state=0
11
->0x3035740119198117
12
->0x50eed0e0fbbe01b4
13
->0x32f693aeb20a902d
14
->0xcb2d7e6fa30bbf4a
15
/dev/null
16
/var/folders/z5/mt8d56zs60qdrttq8zz569280000gn/T/nvimqEnBkf/0
17
count=0, state=0xa
18
->0xd0b7b288d4b50252
19
->0x7d3e33486d9649ba
20
->0xfd8a6ad9f5dcdd71
21
->0x52ad516d7d70941
22
/dev/null
23
count=0, state=0xa
24
->0xfc87d5ec36b6e6fb
25
->0x97af146e595447d6
26
->0xe9b6e35277f3a53f
27
->0xcdea482ac85c1b9f
28
/dev/ttys000
29
/dev/null
30
->0x2427b9269bfe7357
31
/Users/xxxxxx/.cache/nvim/dap.log
32
/Users/xxxxxx/.cache/nvim/lsp.log
33
->0x2427b9269bfe935f
34
->0x2427b9269bfe4477
35
->0x2427b9269bfe5287
36
->0x2427b9269bfe980f
37
->0x2427b9269bfe55a7
38
->0x2427b9269bfe7997
39
->0x2427b9269bfe6547
40
->0x2427b9269bfe327f
41
->0x2427b9269bfe2f5f
42
->0x2427b9269bfe9427
43
->0x2427b9269bfe372f
44
->0x2427b9269bfea2ff
45
->0x2427b9269bfe408f
46
->0x2427b9269bfe31b7
47
->0x2427b9269bfe903f
48
->0x2427b9269bfe6ea7
49
->0x2427b9269bfe7037
50
->(none)
51
->0x2427b9269bfe5caf
52
->0x2427b9269bfe71c7
53
->(none)
54
->0x2427b9269bfe49ef
55
->(none)
56
->0x2427b9269bfe6227
57
->(none)
58
->(none)
59
->0x2427b9269bfe58c7
60
->(none)
61
->0x2427b9269bfe7fd7
62
->0x2427b9269bfe9bf7
63
->0x2427b9269bfe8b8f
64
->0x2427b9269c0eedcf
65
->(none)
66
->0x2427b9269c0ee5ff
67
->0x2427b9269bfe6867
68
->0x2427b9269c0f60a7
69
->0x2427b9269bfe3bdf
70
->(none)
71
->0x2427b9269bfe615f
72
->(none)
73
->0x2427b9269c0f3d7f
74
->0x2427b9269bfe91cf
75
->0x2427b9269c0f35af
76
-0x2427b9269bfe57ff
77
->0x2427b9269c0f198f
78
->0x2427b9269f51886f
79
->0x2427b9269bfe5be7
80
->0x2427b9269c0f1be7
81
->0xb30d4ba5114ec184
82
->0x2427b9269c0f5f17
83
->0xd1a016812d84e8e9
85
->0x2427b9269c0f11bf
86
->(none)
87
->0x2427b9269c0f567f
89
->(none)
91
->(none)
92
->(none)
93
->(none)
94
->(none)
95
->(none)
96
->(none)
97
->(none)
98
->(none)
99
->(none)
100
->(none)
101
->(none)
102
->(none)
103
->(none)
104
->(none)
105
->(none)
106
->(none)
107
->(none)
108
->(none)
109
->(none)
110
->0x2427b9269c0f1caf
111
->(none)
112
->(none)
113
->0x2427b9269c0f06cf
114
->(none)
115
->0x2427b9269c0f134f
116
->0x2427b9269c0ef40f
117
->0x2427b9269c0f486f
118
->0x2427b9269c0f62ff
119
->0x2427b9269f51278f
120
->0x2427b9269c0f021f
121
->0x2427b9269c0f341f
122
->0x2427b9269f51421f
123
->0x2427b9269c0f43bf
124
->0x2427b9269f512d07
125
->(none)
126
->0x2427b9269f517bef
127
->0x2427b9269f51647f
128
->0x2427b9269f519bf7

129
->0x2427b9269f512857
130
->(none)
131
->0x2427b9269f517e47
132
->(none)
133
->0x2427b9269f516f6f
134
->0x2427b9269f5187a7
135
->0x2427b9269f517fd7
136
->0x2427b9269f5137f7
137
->0x2427b9269f51485f
138
->0x2427b9269f513b17
139
->0x2427b9269f517997
140
->0x2427b9269f513fc7
141
->0x2427b9269f51935f
142
->0x2427b9269f517677
143
->0x2427b9269f5143af
144
->0x2427b9269f51453f
145
->0x2427b9269f512dcf
146
->0x2427b9269f513a4f
147
->0x2427b9269f517037
148
->0x2427b9269f51291f
149
->0x2427b9269f515e3f
150
->0x2427b9269f51728f
151
->0x2427b9269f5166d7
152
->0x2427b9269f515f07
153
->0x2427b9269f515b1f
154
->0x2427b9269f513bdf
155
->0x2427b9269f517cb7
156
->0x2427b9269f519297
157
->0x2427b9269f51854f
158
->0x2427b9269f514607
159
->0x2427b9269f515caf
160
->0x2427b9269f513e37
161
->0x2427b9269f516b87
162
->0x2427b9269f512aaf
163
->0x2427b9269f5170ff
164
->0x2427b9269f5130ef
165
->0x2427b9269f5183bf
166
->0x2427b9269f51903f
167
->0x2427b9269f5194ef
168
->0x2427b9269f512537
169
->0x2427b9269f513ca7
170
->0x2427b9269f5182f7
171
->0x2427b9269f514c47
172
->0x2427b9269f51692f
173
->0x2427b9269f512e97
174
->0x2427b9269f515d77
175
->0x2427b9269f514ab7
176
->0x2427b9269f51372f
177
->0x2427b9269f5195b7
178
->0x2427b9269f517357
179
->0x2427b9269f5151bf
180
->0x2427b9269f514927
181
->0x2427b9269f515417
182
->0x2427b9269f439a57
183
->0x2427b9269f513667
184
->0x2427b9269f43a867
185
->0x2427b9269f4390f7
186
->0x2427b9269f43b73f
187
->0x2427b9269f43e0a7
188
->0x2427b9269f4386cf
189
->0x2427b9269f43cb8f
190
->0x2427b9269f43e16f
191
->0x2427b9269f437027
192
->0x2427b9269f439fcf
193
->0x2427b9269f43b807
194
->0x2427b9269f4394df
195
->0x2427b9269f43a9f7
196
->0x2427b9269f43cde7
197
->0x2427b9269f43727f
198
->0x2427b9269f43a47f
199
->0x2427b9269f43d35f
200
->0x2427b9269f4371b7
201
->0x2427b9269f43691f
202
->0x2427b9269f43b41f
203
->0x2427b9269f43c9ff
204
->0x2427b9269f43d107
205
->0x2427b9269f438ab7
206
->0x2427b9269f43a2ef
207
->0x2427b9269f438b7f
208
->0x2427b9269f437e37
209
->0x2427b9269f43bbef
210
->0x2427b9269f43d99f
211
->0x2427b9269f4370ef
212
->0x2427b9269f43dd87
213
->0x2427b9269f436b77
214
->0x2427b9269f43e237
215
->0x2427b9269f43a3b7
216
->0x2427b9269f43ac4f
217
->0x2427b9269f4377f7
218
->0x2427b9269f43b4e7
219
->0x2427b9269f43885f
220
->0x2427b9269f4378bf
221
->0x2427b9269f438e9f
222
->0x2427b9269f43dcbf
223
->0x2427b9269f436f5f
224
->0x2427b9269f437ca7
225
->0x2427b9269f43bd7f
226
->0x2427b9269f43d67f
227
->0x2427b9269f439f07
228
->0x2427b9269f43966f
229
->0x2427b9269f437667
230
->0x2427b9269f4397ff
231
->0x2427b9269f4382e7
232
->0x2427b9269f43af6f
233
->0x2427b9269f437bdf
234
->0x2427b9269f436e97
235
->0x2427b9269f4374d7
236
->0x2427b9269f438477
237
->0x2427b9269f4398c7
238
->0x2427b9269f43b28f
239
->0x2427b9269f4369e7
240
->0x2427b9269f43d4ef
241
->0x2427b9269f438c47
242
->0x2427b9269c0f3677
243
->0x2427b9269f437fc7
244
->0x2427b9269f6309ff
245
->0x2427b9269f62cdd7
246
->0x2427b9269f62bbdf
247
->0x2427b9269bfe89ff
248
->0x2427b9269f62f997
249
->0x2427b9269f62a6c7
250
->0x2427b9269f6320a7
251
->0x2427b9269c0f292f
252
->0x2427b9269f62c21f

[akinsho]

@mherna thanks for running the test. That does look like a lot of files but a lot fewer than the limit. OOI when you were testing was packer freezing at this point? Think we need to catch one of these outputs whilst packer is failing. But you are right it doesn't directly point to packer. I guess one way to check would be whilst it's failing check the files as above then run PackerSync again and see if they increase anymore after that.

I'll keep my eyes out as well and try and do the same. As to why packer is failing I'm pretty sure (could be wrong) that it's because neovim has exhausted the number of files it's allowed to open so when packer tries to create jobs for updating packages it isn't allowed by the OS to create anymore.

[mherna]

@akinsho yeah Packer freezes every time I run it XD. It froze at packer.nvim - syncing 57 / 130 plugins, and the output is from when the command was running. I do see that after it freezes the number of opened files goes back down to 32, which is the wonted number of files any neovim instances opens for me. So it seems Packer correctly closes the files it creates, but it still fails to sync some plugins.

[kyoh86]

I'm facing the same problem... Packer freezes with a message syncing 6 / 79 plugins. Maybe 73 is the limit. When I remove 6 plugins, Packer succeeded updating them.

[kyoh86]

And I tried it on Terminal.app, it's reproduced. It's not a problem of the iTerm2.

[wbthomason]

This issue is bizarre. So far:

• it only happens on macOS
• it happens with different numbers of plugins, but is mitigated by decreasing the number of plugins
• it happens in any terminal
• it seems to mostly happen in long-running sessions
• raising the number of file descriptors per process to an unreasonable level seems to fix it
• packer seems to be closing all its files, but still triggers the issue

Does this seem like an accurate summary of the current knowledge for this issue?

[kyoh86]

it happens with different numbers of plugins, but is mitigated by decreasing the number of plugins

It doesn't happen with 73 plugins in common for everyone, but 74 and later plugins are not syncing well.

[gegoune]

Happening to me with 60odd plugins in alacritty.

[wbthomason]

@cloggier Still on macOS, or another OS?

[akinsho]

@wbthomason I meant to report a bit more on this a little while ago since I'm not 100% sure this is something that packer should fix vs. macos users making the requisite change ie.

Source

Once you’ve done this, the kernel itself will have a maximum number of files but the shell might not. And since most processes that will take up this many files are going to be initiated by the shell you’re gonna want to increase that.

It seems that separate to the total limit of files which are allowed to be opened the shell itself has a limit in macos which I think is easily exceeded for anyone working a lot in the shell

You can actually check the programs using the most files by running

sudo lsof -n | cut -f1 -d' ' | uniq -c | sort | tail

You can see the default limit on mac using launchctl limit maxfiles for me this returns 256. Whereas the above command for me easily returns close to 2000, google (I'm guessing chrome being the worst offender)

So the limit is quite low, out of interest I ran the same thing on linux and I have close to 10,000 files open (most of this TabNine being super greedy/buggy, but point is I see no issues)

I've added ulimit -n 4096 to my ~/.profile for my mac so it sets it on login and don't see this issue anymore.

Theoretically packer could set it as a one off since just running it once is a one off, before it does it's thing but I don't think it should bear that responsibility that would involve messing with a user's system without them knowing which I don't think is worth getting into.

[wbthomason]

I strongly do not want packer to change things like ulimit settings; I think that's too much interference. My concern is mostly why packer triggers this behavior but other plugin managers (presumably) do not.

[akinsho]

@wbthomason I think it isn't just packer that triggers this behaviour, I've seen it on occasion with other things like hexokinase I believe the reason something like vim-plug or paq don't hit this is that they don't open files? at least certainly not in the way that packer does nor does dein also i'd imagine since that will be using vimscript apis. Seems like now that there are a lot of plugins such a packer using luv more things will trigger this for macos users.

[wbthomason]

@akinsho That's good to know. I would expect that any plugin manager using async installation (i.e. Neovim jobs, etc.) would open just as many files as packer, since all of those files except for the packer_compiled file (which is opened once) are for I/O, which e.g. jobstart also opens.

[gegoune]

@wbthomason Yes, alacritty, tmux and Neovim on Mac OS.

I did not reread the whole issue but sometimes I get the message saying that too many files are open and some other times packer just hangs with handful of plugins left for update (out of 60 something).

Therefore I am not sure whether those two issues are exactly the same.

Do you know if Packer actually updates those remaining plugins? If so, perhaps vim-plug's equivalent of diff command, PackerDiff, showing diffs for last Packer{Sync,Update} could be added?

[wbthomason]

@cloggier we have a diff feature (added by @akinsho iirc) in the results display window (press d by default). Are you suggesting something that can run without the results display window, so that you could close Neovim after a hang, restart, and view the results of the last attempted operation?

[wbthomason]

Also, you should be able to look in ~/.cache/nvim/packer.nvim.log to see which operations started/finished. I can add additional debug logging to the relevant paths if there's not enough information in the log.

[gegoune]

Will check logs next time it fails, but have increase ulimit for now.

I meant equivalent of PlugDiff from https://github.com/junegunn/vim-plug#commands. This can be invoke any time to show lat update's status window (I do not mean commits' diffs here).

[kyoh86]

workaround:

require'packer'.init({
  max_jobs=50
})
require'packer'.startup(function()
...

It works.

[smackesey]

I also have this problem. The Packer UI freezes vim every time on Sync/Update/Install. Some notes:

• Freezes on <plugin name> checking updated commit... for some plugin, even with only one plugin listed.
• Occurs in both VimR (an NVIM GUI) and in iTerm2.
• Setting max_jobs (as @kyoh86 suggested) does not fix the problem.
• Setting ulimit -S -n 200048 does not fix the problem.
• Freezes even with PackerInstall
• To quit VimR during the freeze, I don't have to Force Quit. Instead a regular quit (cmd-q) works, but there are several seconds of spinning beach ball before it quits.
• Nothing printed to ~/.cache/nim/packer.nvim.log
• commit 09cc2d (from Aug 26 2021)
• macOS 11.15

Basically the plugin is completely unusable for me because of this mysterious freezing.

[ahmedelgabri]

I started to get the same issue too after adding some new plugins. Which took the number to 76 if I go to 73 plugins as @kyoh86 said, it works fine. Once I add an extra plugin I hit this issue.

• Setting max_jobs does not fix the problem. Even if I set it to 1.
• Setting ulimit -S -n 200048 does not fix the problem.
• I'm using Kitty 0.23.1 on macOS 11.5.2 neovim 0.5.0 & packer https://github.com/wbthomason/packer.nvim/commit/09cc2d615bbc14bca957f941052e49e489d76537
• tailing the log file shows that packer is always stuck at running tasks

[DEBUG Sun 29 Aug 12:20:09 2021 2204420155507] ...config/nvim/pack/packer/start/packer.nvim/lua/packer.lua:565: Running tasks

[akinsho]

Regarding set ulimit -S are people adding this to their shell startup scripts or just running it once? Since it will only apply for the lifetime of the shell, if it isn't re-executed every time you start one.

Another thing to note is that the UI will sometimes block if there is an error somewhere with a plugin which isn't ideal, but I have seen this before if there are issues with a plugin spec

[ahmedelgabri]

@akinsho I didn't add it to any shell startup files. I only ran it inside a shell and tested to see if it will work first or not, before deciding to make it permanent.

[mhanberg]

I started to get the same issue too after adding some new plugins. Which took the number to 76 if I go to 73 plugins as @kyoh86 said, it works fine. Once I add an extra plugin I hit this issue.

* Setting `max_jobs` does not fix the problem. Even if I set it to `1`.

* Setting `ulimit -S -n 200048` does not fix the problem.

* I'm using Kitty `0.23.1` on macOS `11.5.2` neovim `0.5.0` & packer [09cc2d6](https://github.com/wbthomason/packer.nvim/commit/09cc2d615bbc14bca957f941052e49e489d76537)

* `tail`ing the log file shows that packer is always stuck at `running tasks`

[DEBUG Sun 29 Aug 12:20:09 2021 2204420155507] ...config/nvim/pack/packer/start/packer.nvim/lua/packer.lua:565: Running tasks

Chiming in to say I just experienced this as well. I dropped some plugins and now the update window seems to work again

[wbthomason]

@mhanberg/anyone else: I don't suppose you have the specs that you dropped to make this work? This is a mysterious bug; maybe we can isolate specific features, e.g. that are present in the troublesome specs? Though as @smackesey notes, apparently this (sometimes) happens with only 1 plugin spec, so maybe not.

I'm mostly mystified by the inconsistency; plenty of macOS users seem to have no trouble with packer (as far as I'm aware).

[ahmedelgabri]

@wbthomason In my case it didn't really matter which specs/plugins I drop. As long as the total number is <= 73 it works. I can constantly replicate the issue with nearly any 73 plugin combination.

[wbthomason]

Good to know, thanks. I would expect the ulimit or concurrent tasks limit fixes to work for that, but it seems they did not in your case. Maybe there's a race condition that becomes more likely with increasing numbers of plugins? But then I'd expect to see this on non-macOS platforms, unless it's a luv/libuv platform-specific bug...

[akinsho]

@ahmedelgabri it might be worth going through the post around ulimit on your own there are some comments in there that helped me debug the limit and the number of process my shell had running https://superuser.com/questions/433746/is-there-a-fix-for-the-too-many-open-files-in-system-error-on-os-x-10-7-1

[smackesey]

Just reviving this issue and reporting a bit of new info-- I updated to macOS Monterey and was hoping maybe this problem would disappear, but nothing has changed.

[ahmedelgabri]

For me it seems like max_jobs = 70 is the max I can set and makes the issue goes away.

[gotgenes]

FWIW I use the the nvim-treesitter plugin which will launch more processes with TSUpdate command. I found I had to further reduce max_jobs to 60 to allow for that command to also succeed.

[beauwilliams]

I am having the same problem too. Packer has not been able to update my packages for a good 2 months or so. It just freezes.

[beauwilliams]

This fixes my issue. Setting max jobs to 4. I am on MacOSX. https://github.com/wbthomason/packer.nvim/issues/456#issuecomment-955185561

[jryio]

Update: After modifying lunarvim to take max_jobs = 4 I can confirm that @beauwilliams has a working solution for my configuration below. Setting max_jobs = 50 still causes freezes as in #456

---

I am also experiencing a total UI lock and freeze running on macOS

OS Version: macOS Monterey 12.0.1 Laptop: Apple M1 Max chip Terminal: Alacritty (alacritty 0.9.0 (fed349a)) installed via Homebrew Neovim:

NVIM v0.6.0
Build type: Release
LuaJIT 2.1.0-beta3
Compiled by brew@Monterey

Packer Commit: 7f62848f3a92eac61ae61def5f59ddb5e2cc6823

[strdem]

just hit this problem on arch linux with neovim 0.6, all mentioned solutions above did not work out

[towry]

just hit this problem on arch linux with neovim 0.6, all mentioned solutions above did not work out

Add max_jobs=50, then PackerClean and PackerSync works.

[marcelarie]

How can I fix this, where should I put max_jobs ?

[wilkinson4]

How can I fix this, where should I put max_jobs ?

require('packer').startup({
    function(use)
        -- Packer can manage itself
        use {'wbthomason/packer.nvim'}
    end,
    config = {display = {open_cmd = 'leftabove 75vnew \\[packer\\]'}, max_jobs = 10}
})