3

I'm on spacemacs develop, emacs version 27, OSX Mojave 10.14.

After adding the lsp layer and the snippet from the metals documentation here: to my .spacemacs file, treemacs will refuse to expand a directory and display its contents, giving the error "Creating pipe: too many open files"

My ulimit setting are:

$ ulimit -a
-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                       1418
-n: file descriptors                256

I suspect this is related to either metals or lsp-mode creating some large number of files in the compilation process. Though checking lsof:

$ lsof | grep -iE "sbt|ivy2" | wc -l   
    1585

doesn't show too many open files related to sbt or ivy.

Running list-buffers I show only 10-20 buffers; nothing unusual.

When this happens, I cannot even exit Emacs and have to kill -9 the process.

1 Answer 1

2

I had a similar issue with lsp-mode and treemacs, though I am using vanilla Emacs not Spacemacs. I am also using macOS.

From this Reddit thread I discovered that the limits do not appear to be reasonably adjustable:

Emacs uses pselect, which is limited to FD_SETSIZE file descriptors, usually 1024. I suspect you've got one of the file-watching utilities enabled in emacs, which tends to use up a lot of file descriptors.

Is there a way to increase this limit? Or maybe check which utility is using the file descriptors?

(attempted solution that adjusts launchctl's maxfiles limit)

Increasing the maxfiles limit will not change the value of FD_SETSIZE compiled into emacs and the macOS libraries. Emacs would have to move to using poll or kqueue to fully solve this issue.

So the only thing to do is reduce how much watching is going on in your environment.

In my case, I am working on a project that is developed in a monorepo with a huge number of files. I was able to work around the problem by doing two things:

  1. Ensure that the root of the monorepo is not seen by lsp-mode as a workspace. See lsp-workspace-folders-remove.

    Instead, only the subproject that I work on directly is an lsp-mode workspace.

  2. Add a .dir-locals.el files disabling watching in the root of the monorepo:

    ((nil . ((lsp-enable-file-watchers . nil))))
    

    Then add another .dir-locals.el that enables watching in the subproject that I'm working on:

    ((nil . ((lsp-enable-file-watchers . t))))
    
1
  • I had forgotten this issue and failed to follow up on my solution. Thanks for your answer. I edited lsp-session-file, as I discovered somehow my home directory had been added as a project root. I learned this can happen if you enter lsp mode for a stand-alone file living in home.
    – Metropolis
    Jan 28 at 16:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.