Zombie Processes Generated on File Name Generation

[mdko]

• Category
  • fzf binary
  • fzf-tmux script
  • Key bindings
  • Completion
  • Vim
  • Neovim
  • Etc.
• OS
  • Linux
  • Mac OS X
  • Windows
  • Windows Subsystem for Linux
  • Etc.
• Shell
  • bash
  • zsh
  • fish

When starting fzf from a large directory (many files, many subdirectories, e.g. like my home directory), fzf begins getting the files to search through (https://github.com/junegunn/fzf/blob/master/src/core.go#L124, https://github.com/junegunn/fzf/blob/master/src/reader.go#L57), as expected. However, when I exit before it's done finding all the files (pressing ESC or C-c), the shell command it spawned via exec.Command(shell, "-c", command) remains running and does not die. When I run fzf again later and exit early, it will again abandon the spawned process, and it remains unreaped.

I current have FZF_DEFAULT_COMMAND set to rg --files --no-ignore --hidden --follow --glob "!.git/*". Thus in fish shell (likewise in bash and zsh):

$ fzf
... getting lots of files ...
>
<ESC>
$ ps -ef | grep rg
mdko 3622        1    0 15:43 pts/0  00:00:00 sh -c rg --files --no-ignore --hidden --follow --glob "!.git/*"
mdko 3624  3622  99 15:43 pts/0  00:00:00 rg --files --no-ignore --hidden --follow --glob "!.git/*"

I see that the reader code is called before the terminal I/O and event coordination in core.go, so I'm wondering if that has anything to do with not cleaning up these spawned processes.

[junegunn]

Check out #398, and see if it's related. Also make sure to have the latest version of rg.

[mdko]

Yes, it's fixed now; it was related to #398 and not having the latest rg (rg wasn't handling SIGPIPE properly, issue BurntSushi/ripgrep#200). Thanks for taking the time to point that out to me.