High cpu usage in background

[kkga]

I often open a child shell in the current directory (by pressing w) and lf keeps running as a parent process.
I've been using this for years, since I switched to lf and never had any problems.

Recently (I think it started happening after updating to r21), I started noticing that lf often uses 100% of CPU. I can't reproduce what exactly makes it run like this, but it does happen multiple times a day.

Any tips on how to avoid this?

[gokcehan]

@kkga It's not easy to solve these issues without being able to consistently reproduce it. Indeed, there has been changes in how we suspend ui for shell commands in r21 which might be related to this. But I can't say for sure as I haven't experienced it myself. What platform are you running? Maybe you can try changing your shell and/or terminal to see if that helps. There might also be a setting in your configuration file to trigger this issue. Feel free to report here if you can come up with any relevant information.

[OuterHeavenCC]

I'm having the same issue since a few days, I can't reproduce the problem either. I'm using arch linux (dwm + st, zsh shell) on a T440p. I've been trying to change my lfrc for a few days without success.

Edit : Downgraded to r19, it seems to fix the problem.

[kkga]

I'm on Void Linux, the shell is fish 3.2.1.

Here's my config (quite close to default): https://github.com/kkga/dotfiles/blob/master/.config/lf/lfrc

I'm gonna try using a different terminal for a few days to see if it changes anything.

[ecomaikgolf]

Same issue here. lf r21, archlinux, dwm, st, zsh

I usually open lf with the following zshrc funcion

lfcd () {
    tmp="$(mktemp)"
    lf -last-dir-path="$tmp" "$@"
    if [ -f "$tmp" ]; then
        dir="$(cat "$tmp")"
        rm -f "$tmp"
        [ -d "$dir" ] && [ "$dir" != "$(pwd)" ] && cd "$dir"
    fi
}
bindkey -s '^o' 'lfcd\n'

Never had any problems with it until now

How to reproduce

• Open terminal
• Press Ctrl+O (executes the function)
• Go to some dir
• Press w to open a shell
• Close the terminal (kill it with xkill for example)

[DusanLesan]

I am experiencing this every day. I have not figured out any STR. I think that every time before app hijacks whole cpu core, I do navigation to some dir, drop out to shell and after return to lf again
lf r21, archlinux, dwm, alacritty, zsh

[voreisthescore]

Can confirm, issue present on MacOS using ldcd.sh to call lf(21) also causes high background CPU usage since the update.
Shell is zsh, using Kitty as my Term.

[gokcehan]

@ecomaikgolf I tried closing the terminal but still haven't experienced the issue. Can you consistently reproduce it yourself or it happens from time to time?

[ecomaikgolf]

@ecomaikgolf I tried closing the terminal but still haven't experienced the issue. Can you consistently reproduce it yourself or it happens from time to time?

Consistently

lfcd() -> shell (w) -> xkill -> high bakground cpu usage
lfcd() -> shell (w) -> close with Win+q in dwm -> high bakground cpu usage

Before closing/killing it

$ pstree -p | grep lf
           |                                                  |-st(458008)---zsh(458009)---lf(458070)-+-lf(458075)-+-{lf}(458076)
           |                                                  |                                       |            |-{lf}(458077)
           |                                                  |                                       |            `-{lf}(458078)
           |                                                  |                                       |-{lf}(458071)
           |                                                  |                                       |-{lf}(458072)
           |                                                  |                                       |-{lf}(458073)
           |                                                  |                                       |-{lf}(458074)
           |                                                  |                                       |-{lf}(458079)
           |                                                  |                                       |-{lf}(458080)
           |                                                  |                                       |-{lf}(458081)
           |                                                  |                                       |-{lf}(458082)
           |                                                  |                                       |-{lf}(458083)
           |                                                  |                                       |-{lf}(458084)
           |                                                  |                                       |-{lf}(458085)
           |                                                  |                                       |-{lf}(458086)
           |                                                  |                                       `-{lf}(458087)

After killing it, high CPU usage. Maybe the problem is when it detaches from zsh/st when I kill it.

$ pstree -p | grep lf
           |-lf(458070)-+-lf(458075)-+-{lf}(458076)
           |            |            |-{lf}(458077)
           |            |            `-{lf}(458078)
           |            |-{lf}(458071)
           |            |-{lf}(458072)
           |            |-{lf}(458073)
           |            |-{lf}(458074)
           |            |-{lf}(458079)
           |            |-{lf}(458080)
           |            |-{lf}(458081)
           |            |-{lf}(458082)
           |            |-{lf}(458083)
           |            |-{lf}(458084)
           |            |-{lf}(458085)
           |            |-{lf}(458086)
           |            `-{lf}(458087)

[gokcehan]

@ecomaikgolf Good catch, I'm able to reproduce it myself now.

In my case it also happens independent of my terminal and probably window manager as well. Closing the terminal with either window manager shortcut or xkill triggers the behavior. The only related thing I could find is that this only happens with zsh and not bash or fish. Most people here report zsh similarly except for @kkga which I'm not sure why yet. Also, it only happens when I use the lfcd function but not when I run lf regularly.

Indeed the problem is that the process is detached and left behind instead of getting killed. On lf side, we quit when we receive SIGHUP. My guess is that zsh does not send SIGHUP somehow when the terminal is closed while a function is still running. If this is the case, I'm not sure what we can do about it yet. There might be an option about this in zsh or a workaround somehow.

[ecomaikgolf]

In my case it also happens independent of my terminal and probably window manager as well. Closing the terminal with either window manager shortcut or xkill triggers the behavior. The only related thing I could find is that this only happens with zsh and not bash or fish. Most people here report zsh similarly except for @kkga which I'm not sure why yet. Also, it only happens when I use the lfcd function but not when I run lf regularly.

Strange behaviour in zsh. Killing itself in a function still completes the function

Indeed the problem is that the process is detached and left behind instead of getting killed. On lf side, we quit when we receive SIGHUP. My guess is that zsh does not send SIGHUP somehow when the terminal is closed while a function is still running. If this is the case, I'm not sure what we can do about it yet. There might be an option about this in zsh or a workaround somehow.

Wrote this little function in my .zshrc as a hotfix.

TRAPEXIT() {
	 pkill -f "lf -last-dir-path=*"
}

http://zsh.sourceforge.net/Doc/Release/Functions.html

---

But how this started happening in r21 update?

[gokcehan]

@ecomaikgolf I have tried this with previous versions. It seems that signal is skipped in zsh with previous versions as well. But we were using Init function to resume ui before and we simply exit when it fails to initialize the screen. In r21, we switched to Suspend/Resume and I forgot to add error handling for these functions. Now we also exit when Resume fails so the issue should be fixed with the latest commit.

[DusanLesan]

I've been using this since the fix. No issues

[kkga]

I've been using this since the fix. No issues

Same here. No issues on Linux/macOS after the fix.

[4volodin]

Same issue here. lf r21, archlinux, dwm, st, zsh

I usually open lf with the following zshrc funcion

lfcd () {
    tmp="$(mktemp)"
    lf -last-dir-path="$tmp" "$@"
    if [ -f "$tmp" ]; then
        dir="$(cat "$tmp")"
        rm -f "$tmp"
        [ -d "$dir" ] && [ "$dir" != "$(pwd)" ] && cd "$dir"
    fi
}
bindkey -s '^o' 'lfcd\n'

Never had any problems with it until now

How to reproduce

• Open terminal
• Press Ctrl+O (executes the function)
• Go to some dir
• Press w to open a shell
• Close the terminal (kill it with xkill for example)

The issue isn't disappeared
Screen

macOS,
lf version r21

[DusanLesan]

The issue isn't disappeared
Screen

macOS,
lf version r21

The fix may not be released yet. Did you build from source or use the packaged version?

[4volodin]

The issue isn't disappeared
Screen
macOS,
lf version r21

The fix may not be released yet. Did you build from source or use the packaged version?

brew packaged
Yes you're right

[gokcehan]

I have now released r22 which includes the fix. Closing this issue.