[SOLVED] Killing fish reparents some ncurses processes into CPU hogs

Ambrevar · 2017-01-09 08:06:26

I've had issue when killing a fish shell running an ncurses app (fzf, ncdu, cmus, ranger...): it will randomly (about 75% of the time, ymmv) reparent the ncurses process to PID1 and turn it into a CPU hog.

I am using URxvt, Awesome, ncurses 6.0+ (stock Arch), fish (stock Arch) or fish-git.

I have reported the bug on the fish bug tracker:

https://github.com/fish-shell/fish-shell/issues/3644

The core developer(s) does not seem to be able to reproduce, so I suspect there might be something Arch specific.

Can anybody reproduce here?

Last edited by Ambrevar (2017-02-27 08:19:25)

bstaletic · 2017-01-09 10:48:52

First thing I'd try is reproducing the problem from TTY, using bash. If you manage to reproduce that way, it would mean that fish, URxvt and Awesome are not to blame. Which only leaves ncurses.

If you caan't reproduce the issue, try fish from TTY. That would still leave out anything that has to do with graphical interface, even though I highly doubt the culprit lays there.

Ambrevar · 2017-01-09 12:01:19

I cannot reproduce with either xterm+fish or URxvt+bash.
I hadn't thought of TTY, so I tried anyways: rightfully so, TTY+fish will create a CPU hog!
So Awesome has nothing to do with it.
Still weird that I cannot reproduce with xterm.

bstaletic · 2017-01-10 12:39:39

Is it possibly that you just didn't test it enough times in xterm? My bet is still on some obscure fish bug.

Maybe fish in combination with some $TERM settings creates the issue.
Try lying about your $TERM in xterm, by setting it to, let's say "linux", as that is what it is set to in TTY.

Trilby · 2017-01-10 12:48:49

It sounds like fish is failing to send and/or propogate signals (SIGTERM/SIGKILL) to child process resulting in broken pipes for any children that require standard stream connections (all the ones you mention do).

Ideally, the child programs should detect the broken pipe and exit gracefully. So really it is a bug on their end too. But it seems the de facto standard is for many of these programs to rely on the shell or other parent program to let them know then the terminal is gone.

Ambrevar · 2017-01-10 15:54:45

Smart guess with setting the TERM env variable. Just tried... And no, xterm won't trigger the bug. The other way around, setting TERM to xterm in urxvt will still trigger the issue.

xterm most definitely works: I've tried about 50 times, while it only takes 2-3 times with urxvt to trigger the bug.

The fish dev suggested to report that to ranger, fzf and co. but there is more to it. The bug does not occur with other shells.

Ambrevar · 2017-02-27 08:19:08

Fish 2.5 fixes this.

Arch Linux

#1 2017-01-09 08:06:26

[SOLVED] Killing fish reparents some ncurses processes into CPU hogs

#2 2017-01-09 10:48:52

Re: [SOLVED] Killing fish reparents some ncurses processes into CPU hogs

#3 2017-01-09 12:01:19

Re: [SOLVED] Killing fish reparents some ncurses processes into CPU hogs

#4 2017-01-10 12:39:39

Re: [SOLVED] Killing fish reparents some ncurses processes into CPU hogs

#5 2017-01-10 12:48:49

Re: [SOLVED] Killing fish reparents some ncurses processes into CPU hogs

#6 2017-01-10 15:54:45

Re: [SOLVED] Killing fish reparents some ncurses processes into CPU hogs

#7 2017-02-27 08:19:08

Re: [SOLVED] Killing fish reparents some ncurses processes into CPU hogs

Board footer