Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Kitty v26 consuming a lot of CPU if started by keyboard shortcut #5444

Closed
thatAkiraFox opened this issue Aug 29, 2022 · 5 comments
Closed

Kitty v26 consuming a lot of CPU if started by keyboard shortcut #5444

thatAkiraFox opened this issue Aug 29, 2022 · 5 comments
Labels

Comments

@thatAkiraFox
Copy link

Describe the bug
Apparently every time I start kitty v26 via keyboard shortcut it starts consuming a lot of CPU (with a crash reported in the background) regardless of the config file used.

Starting kitty from command line makes it work fine with no crash.

To Reproduce
Steps to reproduce the behavior:

  1. Start kitty via keyboard shortcut (KDE in my case)
  2. Check CPU usage with something like htop or btop (which I use)
  3. Kitty uses 100% on one core and makes the CPU temps spike

Screenshots

image

/usr/bin/kitty is the one started via keyboard shortcut, while kitty is the one started via command line (or even via .desktop file).

Here the CPU temp spike can also be seen, in the same conditions by just closing /usr/bin/kitty the CPU temps fall down to 40 Celsius.

Environment details

kitty 0.26.0 created by Kovid Goyal
Linux dumbFoxBox 5.19.4-arch1-1 #1 SMP PREEMPT_DYNAMIC Thu, 25 Aug 2022 17:31:12 +0000 x86_64
Arch Linux 5.19.4-arch1-1 (/dev/tty)

DISTRIB_ID="Arch"
DISTRIB_RELEASE="rolling"
DISTRIB_DESCRIPTION="Arch Linux"
Running under: Wayland
Frozen: False
Paths:
  kitty: /usr/bin/kitty
  base dir: /usr/lib/kitty
  extensions dir: /usr/lib/kitty/kitty
  system shell: /usr/bin/zsh

Config options different from defaults:

Important environment variables seen by the kitty process:
	PATH                                /usr/local/sbin:/usr/local/bin:/usr/bin:/var/lib/flatpak/exports/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
	LANG                                en_US.UTF-8
	SHELL                               /usr/bin/zsh
	DISPLAY                             :1
	WAYLAND_DISPLAY                     wayland-0
	USER                                akira
	XCURSOR_SIZE                        24
	XDG_ACTIVATION_TOKEN                kwin-168
	XDG_CONFIG_DIRS                     /home/akira/.config/kdedefaults:/etc/xdg
	XDG_CURRENT_DESKTOP                 KDE
	XDG_DATA_DIRS                       /home/akira/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share
	XDG_RUNTIME_DIR                     /run/user/1000
	XDG_SEAT                            seat0
	XDG_SEAT_PATH                       /org/freedesktop/DisplayManager/Seat0
	XDG_SESSION_CLASS                   user
	XDG_SESSION_DESKTOP                 KDE
	XDG_SESSION_ID                      2
	XDG_SESSION_PATH                    /org/freedesktop/DisplayManager/Session1
	XDG_SESSION_TYPE                    wayland
	XDG_VTNR                            2

Additional context

Here's the crash popping up in journalctl -f every time kitty is started via keyboard shortcut:

Aug 29 20:37:14 dumbFoxBox systemd[571]: Started kitty - Terminal emulator.
Aug 29 20:37:14 dumbFoxBox kwin_wayland_wrapper[4708]: [241 20:37:14.482691] Traceback (most recent call last):
Aug 29 20:37:14 dumbFoxBox kwin_wayland_wrapper[4708]:   File "/usr/bin/../lib/kitty/kitty/main.py", line 446, in main
Aug 29 20:37:14 dumbFoxBox kwin_wayland_wrapper[4708]:     _main()
Aug 29 20:37:14 dumbFoxBox kwin_wayland_wrapper[4708]:   File "/usr/bin/../lib/kitty/kitty/main.py", line 418, in _main
Aug 29 20:37:14 dumbFoxBox kwin_wayland_wrapper[4708]:     prewarm = fork_prewarm_process(opts)
Aug 29 20:37:14 dumbFoxBox kwin_wayland_wrapper[4708]:   File "/usr/bin/../lib/kitty/kitty/prewarm.py", line 608, in fork_prewarm_process
Aug 29 20:37:14 dumbFoxBox kwin_wayland_wrapper[4708]:     exec_main(stdin_read, stdout_write, death_notify_write)
Aug 29 20:37:14 dumbFoxBox kwin_wayland_wrapper[4708]:   File "/usr/bin/../lib/kitty/kitty/prewarm.py", line 570, in exec_main
Aug 29 20:37:14 dumbFoxBox kwin_wayland_wrapper[4708]:     if not sys.stdout.line_buffering:  # happens if the parent kitty instance has stdout not pointing to a terminal
Aug 29 20:37:14 dumbFoxBox kwin_wayland_wrapper[4708]: AttributeError: 'NoneType' object has no attribute 'line_buffering'

Also yes, I tried starting it with kitty --config NONE but obviously the issue won't show there since starting kitty from the command line makes it work just fine, but I tried deleting the config file altogether and starting it from keyboard shortcut still causes this issue.

@kovidgoyal
Copy link
Owner

What is in this desktop file you are launching with?

@kovidgoyal
Copy link
Owner

Actually I think I know the cause. Your desktop launcher is launching kitty with broken stdio stream stdout/stderr/stdin. This causes the new prewarming code to fail. You can work around it by changing the kitty.desktop file to use

Exec=sh -c "kitty > /dev/null 2> /dev/null </dev/null"

You might need to instead create a wrapper script f it doesnt like complex args in the Exec field.

I suppose I will have to detect this brokenness in the kitty launcher and redirect the stdio streams to /dev/null before starting up python. Sigh.

@thatAkiraFox
Copy link
Author

What is in this desktop file you are launching with?

I just meant to say that I was launching kitty via the usual app launcher / krunner, nothing special going on

Actually I think I know the cause. Your desktop launcher is launching kitty with broken stdio stream stdout/stderr/stdin. This causes the new prewarming code to fail. You can work around it by changing the kitty.desktop file to use

Exec=sh -c "kitty > /dev/null 2> /dev/null </dev/null"

You might need to instead create a wrapper script f it doesnt like complex args in the Exec field.

I suppose I will have to detect this brokenness in the kitty launcher and redirect the stdio streams to /dev/null before starting up python. Sigh.

Gonna try later and let you know, thanks!

@thatAkiraFox
Copy link
Author

Ok, using a wrapper to start kitty solves the issue, thanks!

@thatAkiraFox
Copy link
Author

Can confirm that version 0.26.2 fixes the issue.

Thanks a lot!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants