wezterm gets into a high-event/high-power-consumption state until all windows are closed
Author: nagisaCreated Sep 15, 2025Updated Sep 14, 2026
Labelsbugneeds:triage
What Operating System(s) are you seeing this problem on?
Linux Wayland
Which Wayland compositor or X11 Window manager(s) are you using?
wayland/niri.
WezTerm version
bf9a2aeeb
Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?
Yes, and I updated the version box above to show the version of the nightly that I tried
Describe the bug
I have been noticing that at some point my device would consume a non-insignificant amount of extra power while idle. I troubleshooted this down to it being partly due to wezterm, even though I would only have one or two windows sitting in shell doing nothing.
In a brief investigation I would see that powertop would show aroud 100+ events/s consistently and the affected process would be making a lot of syscalls along the lines of
[pid 1434759] 00:15:52.535475 <... epoll_wait resumed>, [{events=EPOLLIN, data=0xfffffffd}], 8, -1) = 1
[pid 1434761] 00:15:52.535479 futex(0x556f831c8b40, FUTEX_WAIT_BITSET_PRIVATE, 2, {tv_sec=202717, tv_nsec=579747189}, FUTEX_BITSET_MATCH_ANY <unfinished ...>
[pid 1434759] 00:15:52.535483 write(5, "\1\0\0\0\0\0\0\0", 8) = 8
[pid 1434759] 00:15:52.535495 read(12, "x", 64) = 1
[pid 1434759] 00:15:52.535505 epoll_wait(14 <unfinished ...>
[pid 1434761] 00:15:52.535582 <... futex resumed>) = -1 ETIMEDOUT (Connection timed out)
[pid 1434761] 00:15:52.535589 timerfd_settime(6, 0, {it_interval={tv_sec=0, tv_nsec=0}, it_value={tv_sec=0, tv_nsec=0}}, {it_interval={tv_sec=0, tv_nsec=0}, it_value={tv_sec=0, tv_nsec=0}}) = 0
[pid 1434761] 00:15:52.535602 epoll_ctl(4, EPOLL_CTL_MOD, 6, {events=EPOLLIN|EPOLLPRI|EPOLLERR|EPOLLHUP|EPOLLONESHOT, data=0xffffffffffffffff}) = 0
[pid 1434761] 00:15:52.535615 epoll_pwait(4, [{events=EPOLLIN, data=0xffffffffffffffff}], 1024, 0, NULL, 1) = 1
[pid 1434761] 00:15:52.535628 read(5, "\1\0\0\0\0\0\0\0", 8) = 8
[pid 1434761] 00:15:52.535644 epoll_ctl(4, EPOLL_CTL_MOD, 5, {events=EPOLLIN|EPOLLPRI|EPOLLERR|EPOLLHUP|EPOLLONESHOT, data=0xffffffffffffffff}) = 0
[pid 1434761] 00:15:52.535656 write(13, "x", 1) = 1
[pid 1434759] 00:15:52.535665 <... epoll_wait resumed>, [{events=EPOLLIN, data=0xfffffffd}], 8, -1) = 1
[pid 1434761] 00:15:52.535669 futex(0x556f831c8b40, FUTEX_WAIT_BITSET_PRIVATE, 2, {tv_sec=202717, tv_nsec=579937121}, FUTEX_BITSET_MATCH_ANY <unfinished ...>
[pid 1434759] 00:15:52.535674 write(5, "\1\0\0\0\0\0\0\0", 8) = 8
[pid 1434759] 00:15:52.535687 read(12, "x", 64) = 1
[pid 1434759] 00:15:52.535699 epoll_wait(14 <unfinished ...>
[pid 1434761] 00:15:52.535772 <... futex resumed>) = -1 ETIMEDOUT (Connection timed out)
[pid 1434761] 00:15:52.535778 timerfd_settime(6, 0, {it_interval={tv_sec=0, tv_nsec=0}, it_value={tv_sec=0, tv_nsec=0}}, {it_interval={tv_sec=0, tv_nsec=0}, it_value={tv_sec=0, tv_nsec=0}}) = 0
[pid 1434761] 00:15:52.535798 epoll_ctl(4, EPOLL_CTL_MOD, 6, {events=EPOLLIN|EPOLLPRI|EPOLLERR|EPOLLHUP|EPOLLONESHOT, data=0xffffffffffffffff}) = 0
[pid 1434761] 00:15:52.535810 epoll_pwait(4, [{events=EPOLLIN, data=0xffffffffffffffff}], 1024, 0, NULL, 1) = 1
[pid 1434761] 00:15:52.535822 read(5, "\1\0\0\0\0\0\0\0", 8) = 8
[pid 1434761] 00:15:52.535837 epoll_ctl(4, EPOLL_CTL_MOD, 5, {events=EPOLLIN|EPOLLPRI|EPOLLERR|EPOLLHUP|EPOLLONESHOT, data=0xffffffffffffffff}) = 0
[pid 1434761] 00:15:52.535848 write(13, "x", 1) = 1
[pid 1434759] 00:15:52.535856 <... epoll_wait resumed>, [{events=EPOLLIN, data=0xfffffffd}], 8, -1) = 1This behaviour is particularly surprising, because I cannot see it at the start-up and it only begins some time into the process' lifetime.
The thread stack-traces aren't particularly revealing, as would be expected:
Thread 61 (Thread 0x7fdbb05166c0 (LWP 1434761) "async-io"):
#0 0x0000556f650afa50 in polling::epoll::Poller::wait ()
#1 0x0000556f650b109e in polling::Poller::wait ()
#2 0x0000556f650a2a08 in async_io::reactor::ReactorLock::react ()
#3 0x0000556f650a8a72 in async_io::driver::main_loop ()
#4 0x0000556f650a7d76 in std::sys::backtrace::__rust_begin_short_backtrace ()
#5 0x0000556f650a9dde in core::ops::function::FnOnce::call_once{{vtable.shim}} ()
#6 0x0000556f6522d8df in std::sys::pal::unix::thread::Thread::new::thread_start ()
#7 0x00007fdbb0a9e97a in start_thread () from /nix/store/8p33is69mjdw3bi1wmi8v2zpsxir8nwd-glibc-2.40-66/lib/libc.so.6
#8 0x00007fdbb0b26d2c in __clone3 () from /nix/store/8p33is69mjdw3bi1wmi8v2zpsxir8nwd-glibc-2.40-66/lib/libc.so.6
Thread 1 (Thread 0x7fdbb071ef00 (LWP 1434759) "wezterm-gui"):
#0 0x00007fdbb0b271fa in epoll_wait () from /nix/store/8p33is69mjdw3bi1wmi8v2zpsxir8nwd-glibc-2.40-66/lib/libc.so.6
#1 0x0000556f64cd5812 in mio::poll::Poll::poll ()
#2 0x0000556f642f1e71 in <window::os::wayland::connection::WaylandConnection as window::connection::ConnectionOps>::run_message_loop ()
#3 0x0000556f634361bf in wezterm_gui::run_terminal_gui ()
#4 0x0000556f6343912e in wezterm_gui::main ()
#5 0x0000556f633ebf83 in std::sys::backtrace::__rust_begin_short_backtrace ()
#6 0x0000556f635c2669 in std::rt::lang_start::{{closure}} ()
--Type <RET> for more, q to quit, c to continue without paging--
#7 0x0000556f65217eb0 in std::rt::lang_start_internal ()
#8 0x0000556f63442b25 in main ()I also made a sampling profile hoping that I would be able to catch something interesting, to no avail: https://share.firefox.dev/47ENlvX
To Reproduce
I haven't been able to reliably trigger this problem. Before writing this issue I thought that this might have been caused by whatever integration for ssh, but I wasn't able to verify 100%. However I do reliably end up seeing this by the end of a day.
This has also been present since a long time ago.
Configuration
local wezterm = require 'wezterm'
local config = wezterm.config_builder()
local font = wezterm.font { family = "Source Code Pro Medium" }
config.font = font
config.font_size = 11
config.colors = {
foreground = '#ffffff',
background = '#000000',
cursor_bg = '#888888',
cursor_fg = '#000000',
cursor_border = '#666666',
selection_fg = '#ffffff',
selection_bg = '#333333',
scrollbar_thumb = '#bebebe',
split = '#333333',
ansi = {'#111111', '#d36265', '#cfefb3', '#e7e18c', '#5297cf', '#963c59', '#5e7175', '#bebebe'},
brights = {'#666666', '#ef8171', '#cfefb3', '#fff796', '#74b8ef', '#b85e7b', '#a3babf', '#ffffff'},
compose_cursor = '#d78c3d',
-- copy_mode_active_highlight_bg = { Color = '#000000' },
-- copy_mode_active_highlight_fg = { AnsiColor = 'Black' },
-- copy_mode_inactive_highlight_bg = { Color = '#52ad70' },
-- copy_mode_inactive_highlight_fg = { AnsiColor = 'White' },
-- quick_select_label_bg = { Color = 'peru' },
-- quick_select_label_fg = { Color = '#ffffff' },
-- quick_select_match_bg = { AnsiColor = 'Navy' },
-- quick_select_match_fg = { Color = '#ffffff' },
}
config.window_frame = {
font = font,
font_size = 10,
active_titlebar_bg = "none",
inactive_titlebar_bg = "none",
}
config.window_padding = {
left = 5, right = 5, top = 0, bottom = 0
}
config.use_dead_keys = false
config.window_background_opacity = 0.9999999
config.alternate_buffer_wheel_scroll_speed = 0
return configExpected Behavior
Wezterm should not get into this mode where its async-io thread keeps itself busy at ~100Hz.
Logs
Debug Overlay
wezterm version: 20250909-070512-bf9a2aee x86_64-unknown-linux-gnu
Window Environment: Wayland
Lua Version: Lua 5.4
OpenGL: AMD Radeon RX 7800 XT (radeonsi, navi32, LLVM 19.1.7, DRM 3.64, 6.16.5) 4.6 (Compatibility Profile) Mesa 25.2.2
Enter lua statements or expressions and hit Enter.
Press ESC or CTRL-D to exit
00:11:03.937 ERROR wezterm_mux_server_impl::local > writing pdu data buffer: Broken pipe (os error 32)
04:17:29.031 ERROR wezterm_mux_server_impl::local > writing pdu data buffer: Broken pipe (os error 32)
04:17:47.848 INFO wezterm_gui::termwindow > clicking <snip>
04:18:08.814 ERROR wezterm_mux_server_impl::local > writing pdu data buffer: Broken pipe (os error 32)
04:18:11.155 ERROR wezterm_mux_server_impl::local > writing pdu data buffer: Broken pipe (os error 32)
12:24:38.901 INFO wezterm_gui::termwindow > clicking <snip>
12:25:34.662 INFO wezterm_gui::termwindow > clicking <snip>
12:25:58.638 INFO wezterm_gui::termwindow > clicking <snip>
13:55:21.937 ERROR wezterm_mux_server_impl::local > writing pdu data buffer: Broken pipe (os error 32)
19:20:10.414 ERROR wezterm_mux_server_impl::local > writing pdu data buffer: Broken pipe (os error 32)
23:38:37.897 ERROR wezterm_mux_server_impl::local > writing pdu data buffer: Broken pipe (os error 32)
23:40:33.317 ERROR wezterm_mux_server_impl::local > writing pdu data buffer: Broken pipe (os error 32)
23:41:18.218 ERROR wezterm_mux_server_impl::local > writing pdu data buffer: Broken pipe (os error 32)
23:42:34.712 ERROR wezterm_mux_server_impl::local > writing pdu data buffer: Broken pipe (os error 32)
23:43:36.687 ERROR wezterm_mux_server_impl::local > writing pdu data buffer: Broken pipe (os error 32)Anything else?
This machine goes to sleep relatively frequently. This may or may not be a factor.
Source: wezterm/wezterm