Kill Yazi when closing a window without quitting yazi

[Brixy]

What system are you running Yazi on?

Linux Wayland

What terminal are you running Yazi in?

foot version: 1.17.2 +pgo +ime +graphemes -assertions

yazi --debug output

Yazi
    Version: 0.2.5 (9f7a1f6 2024-07-15)
    Debug  : false
    OS     : linux-x86_64 (unix)

Ya
    Version: 0.2.5

Emulator
    Emulator.via_env: ("foot", "")
    Emulator.via_csi: Ok(Foot)
    Emulator.detect : Foot

Adapter
    Adapter.matches: Sixel

Desktop
    XDG_SESSION_TYPE: Some("wayland")
    WAYLAND_DISPLAY : Some("wayland-1")
    DISPLAY         : Some(":0")

SSH
    shared.in_ssh_connection: false

WSL
    /proc/sys/fs/binfmt_misc/WSLInterop: false

Variables
    SHELL              : Some("/usr/bin/bash")
    EDITOR             : Some("helix")
    ZELLIJ_SESSION_NAME: None
    YAZI_FILE_ONE      : None
    YAZI_CONFIG_HOME   : None

Text Opener
    default: Some(Opener { run: "$EDITOR \"$@\"", block: true, orphan: false, desc: "$EDITOR", for_: None, spread: true })
    block  : Some(Opener { run: "$EDITOR \"$@\"", block: true, orphan: false, desc: "$EDITOR", for_: None, spread: true })

tmux
    TMUX   : false
    Version: No such file or directory (os error 2)

Dependencies
    file             : 5.45
    ueberzugpp       : No such file or directory (os error 2)
    ffmpegthumbnailer: No such file or directory (os error 2)
    magick           : 7.1.1-34
    fzf              : 0.53.0
    fd               : 10.1.0
    rg               : 14.1.0
    chafa            : No such file or directory (os error 2)
    zoxide           : 0.9.4
    unar             : No such file or directory (os error 2)
    jq               : No such file or directory (os error 2)

Did you try the latest nightly build to see if the problem got fixed?

Yes, and I updated the debug information above (yazi --debug) to the nightly that I tried

Describe the bug

I use a tiling window manager (river).

When I open yazi within a window and then close the window, yazi is not killed. btm shows a very high CPU usage for yazi then.

When I open my editor (helix) from yazi and then close the window, helix is not killed instead (but yazi is).

Expected Behavior

I would expect yazi and any program opened from within yazi to be killed when closing a window.

To Reproduce

1

• Open a window in your window manager.
• Open yazi.
• Close the Window.
• Process yazi was not killed.

2

• Open a window in your window manager.
• Open yazi.
• Open helix from within yazi.
• Close the Window.
• Process helix was not killed.

Configuration

None/default

Anything else?

Although a window manager, a shell, yazi (and an editor) are involved, this seems to be yazi related:

If the steps listed above are reproduced with nnn, everything works as expected, i.e. nnn (or helix) is killed when a containing window is closed.

[sxyazi]

I can't reproduce this issue on my macOS and Linux VM

screenshot-001757.mp4

When I kill the terminal window using the process manager, Yazi exits as expected. I don't use a window manager myself, is this issue only reproducible when killing the window through a window manager (If so, what signal does the window manager send when killing the window?)? What happens if the window is killed using the process manager? What about normally closing the window instead of killing it?

[Brixy]

Thanks for your quick reply.

To narrow it down I also tested this with hyprland. The bevahior is the same. (Current system is Artix/wayland.)

Then I tested this on a different computer. OS is chimera linux/wayland, window manager niri. The problem did not occur here.

So, it could be an Artix-related problem. But this would be strange because I installed river and hyprland with the package manager. Another strange thing is that this does not happen with nnn or the combination nnn/helix.

is this issue only reproducible when killing the window through a window manager (If so, what signal does the window manager send when killing the window?)?

Main PC (Artix): Windows are closed with a key binding, the underlying river command is riverctl close.

If I launch helix right from the shell (not from within yazi) and close the river window, helix is properly closed (or killed?).

Does this help you? Anything I can test? If this is not yazi-related, please just close this issue ;-)

[sxyazi]

What if you kill the window (process) through Task Manager, or close the window normally (by clicking the window's X button), instead of using the window manager? And is this limited to foot, or how do other terminal emulators behave?

[Brixy]

Same behavior with alacritty.

Here's a screenshot. Windows don't have any closing buttons because the tested window managers are almost keyboard only driven. Yet, riverctl close is the regular closing command. It does not kill windows.

What if you kill the window (process) through Task Manager,

Not quite sure. It's possible to kill river/hyprland altogether from e.g. btm, but windows are not listed separately. Of course, it's possible to just kill yazi (or helix, launched within yazi).

Thanks again!

[sxyazi]

Could you upload a perf.data (created with perf record -g) so I can check where the program is hanging? Please make sure to build Yazi in debug mode (no --release flag)

[Brixy]

Hope this helps. Yazi runs perfectly -- as long as I don't just close its river window.

Unfortunately, I cannot simulate the problem. Something like this does not work. (I've never used perf before.)

perf record -g riverctl spawn "TERMINAL yazi"    

perf.zip

EDIT: One more piece of information I didn't mention.

I use the key binding for riverctl close always and for all programs -- GUIs like firefox or TUIs within $TERMINAL. I've never used firefox's context menu for closing it. Never noticed an issue over the years.

[sxyazi]

There's no debugging symbols in perf.data. Did you build Yazi in debug mode? What does yazi --debug say?

[Brixy]

Yes, compiled yazi with cargo build.

yazi --debug prompts this

Yazi
    Version: 0.2.5 (ed6ae00 2024-07-16)
    Debug  : true
    OS     : linux-x86_64 (unix)

[sxyazi]

That's so weird, is riverctl spawn using the debug mode of Yazi? What does which yazi say?

[Brixy]

which correctly points to ~/.local/bin. (I moved yazi in debug more to this location.)

This is what I used. Correct?

perf record -g yazi

Really sorry for bothering you! THX!

[sxyazi]

How about using an absolute path? Like this:

perf record -g /path/to/yazi

Really sorry for bothering you! THX!

No problem, thanks so much for being patient and helping to reproduce this issue!

[Brixy]

perf2.zip

OK. Pointing to target/debug/yazi.

I keep thinking about if this can be related to Artix. I've been -- super happily -- using yazi for almost a year, and I just noticed this on Artix ... But as mentioned; no other program is affected.

[sxyazi]

Please run perf archive in the same directory as perf.data, then upload the generated tar.bz2 file - sorry I forgot to mention this command.

[Brixy]

Here's a download link.

[sxyazi]

It looks like only some Lua code was executed. Do you have any config files? Would you mind uploading them? What would happen if just use the default config (mv ~/.config/yazi ~/.config/yazi.bak)? Does Yazi spike CPU usage right after startup, or only when exiting? Did this start with recent commits?

[Brixy]

I tested with the default config before opening this issue. (But I'll attach my configs. No flavors or plugins are used.)

Does Yazi spike CPU usage right after startup, or only when exiting? Did this start with recent commits?

It only spikes CPU when I close the window running yazi with my file manager, which also should close yazi. Then I always need to pkill yazi.

If yazi is closed using quit everything works perfectly, no CPU spikes at all. That's why I tested closing many other programs with river before opening this issue.

But with a tiling window manager, you actually just use Super+Q to close any windows including the programs running in these windows -- and it's what I have done for years ;-)

conf.zip

[Brixy]

Found a solution by chance: I changed the login shell to dash, and the issue disappeared completely. So, the initial issue might be related to bash/Artix/yazi?!

If nobody else has this issue with bash, maybe this topic can be closed.

[sxyazi]

I suspect this might be related to Yazi's signal system - possibly, Yazi isn't handling the signals correctly, or isn't receiving them at all when the window/shell is closed.

I made a PR to reimplement the signal handling, but I'm not sure if it will actually fix the issue. Could you give it a try? #1307

[Brixy]

Thanks so much for your efforts.

I just compiled yazi from your PR, switched back to bash as the login shell, and it's working perfectly. I closed multiple yazi windows (and editor windows launched by yazi) using the WM, and all yazi processes were closed. (Unfortunately I can't tell you for sure whether your PR alone solved this issue or -- additionally -- the change away and back from Artix's default login shell.)

Thank you!

[sxyazi]

Glad to see some changes have taken place, though I'm not sure what caused the issue and if that PR really fixed it.

Anyway, let's merge it and close this issue for now. I'll keep an eye out to see if anyone else encounters similar problems. If you find any other clues, feel free to reply to this issue or create a new one.

[Brixy]

Glad to see some changes have taken place, though I'm not sure what caused the issue and if that PR really fixed it.

Finally had the chance to go back to an Artix installation. I can now confirm, that your PR definitely solved this issue.

Same problem with my old, pre-PR binary, but everything works perfectly with a freshly compiled binary or the package manager's 0.3 version.

Thanks again!

[sxyazi]

That's great! Thank you for letting me know this!

[github-actions]

I'm going to lock this issue because it has been closed for 30 days. ⏳
This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.