ultrabug / py3status

py3status is an extensible i3status wrapper written in python

Home Page:https://ultrabug.github.io/py3status/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

100% cpu usage when called outside of a graphical terminal or i3

spiderforrest opened this issue · comments

Describe the bug
This is a weird one. I've been writing a script to use py3status with awesomewm, and I noticed when awesome spawned py3status, it would use 100% of one cpu core. After investigating, I found a number of methods of calling py3status that would trigger this, and the pattern seemed to be having a parent process that either isn't capturing output or is possibly capturing it in a nonstandard way? I'm not sure.

This behavior is consistent and I have been able to reproduce it on multiple machines. No configuration changes seem to change it-I tried with `-c /dev/null' as well as several single module configurations, and the issue behaves the same. (appearing when called from a non terminal source other than i3.)

Your py3status version
Tested on two machines:
py3status version 3.50 (python 3.11.3) on sway
py3status version 3.47 (python 3.11.2) on i3

To Reproduce
Tested with several configurations:
order += "clock"
just running with py3status -c /dev/null
and my personal configuration, that shouldn't be useful but it can be found at here in my dotfiles repo

I primarily tested by running it with j4-dmenu-desktop, however, it also appeared with:
-the regular dmenu
-being called from lua by my awesomewm configuration(here's the lua code for awesome's spawn calls, if it ends up helping)
-I made a bash script that just launched py3status and told a file manager to launch it with the command bash, at one point

The commands I tried:
py3status
py3status -c /dev/null
py3status -n 1
py3status -s
py3status -g
py3status -m
py3status --wm sway
py3status --wm i3
py3status -n 1 -c /dev/null
py3status -m -b -s -n 1 --wm sway
bash -c "py3status -m -b -s -n 1 --wm sway"
py3status >> /dev/null
(and probably a few more that I forgot)

I tested most of those commands inside a terminal emulator as well-the error never occurred.

~30 seconds of top logging usage:

$ top | grep py3
 250515 spider    20   0  630908  30636  11776 S  93.8   0.2   0:04.77 py3status
 250515 spider    20   0  630908  30636  11776 S  99.7   0.2   0:07.77 py3status
 250515 spider    20   0  630972  30636  11776 S  99.3   0.2   0:10.76 py3status
 250515 spider    20   0  630908  30636  11776 S  99.0   0.2   0:13.74 py3status
 250515 spider    20   0  630908  30636  11776 S 100.0   0.2   0:16.74 py3status
 250515 spider    20   0  630908  30636  11776 S  99.3   0.2   0:19.73 py3status
 250515 spider    20   0  630908  30636  11776 S  99.0   0.2   0:22.71 py3status
 250515 spider    20   0  630908  30636  11776 S  99.3   0.2   0:25.70 py3status
 250515 spider    20   0  630908  30636  11776 S  99.7   0.2   0:28.70 py3status
 250515 spider    20   0  630908  30636  11776 S  99.3   0.2   0:31.68 py3status
 250515 spider    20   0  630908  30636  11776 S  99.7   0.2   0:34.68 py3status

Here's a bit of debug logging with no configuration-I couldn't spot anything different in logs where the bug was happening and logs where it wasn't.
Launched as py3status -c /dev/null -b -d -l /home/spider/nulllog from j4-dmenu-desktop

2023-05-10 12:24:08 INFO ========
2023-05-10 12:24:08 INFO Starting py3status version 3.50 python 3.11.3
2023-05-10 12:24:08 INFO window manager: sway
2023-05-10 12:24:08 INFO config file: /dev/null
2023-05-10 12:24:08 ERROR Your configuration file does not list any module to be loaded with the "order" directive. Please try to fix this and reload i3wm (Mod+Shift+R)
2023-05-10 12:24:08 INFO modules include paths: []
2023-05-10 12:24:23 INFO received SIGTERM
2023-05-10 12:25:39 INFO ========
2023-05-10 12:25:39 INFO Starting py3status version 3.50 python 3.11.3
2023-05-10 12:25:39 INFO window manager: sway
2023-05-10 12:25:39 INFO py3status started with config {'dbus_notify': True, 'i3status_config_path': PosixPath('/dev/null'), 'debug': True, 'gevent': False, 'include_paths': [], 'log_file': PosixPath('/home/spider/nulllog'), 'standalone': False, 'cache_timeout': 60, 'i3status_path': PosixPath('/usr/bin/i3status'), 'wm': {'msg': 'swaymsg', 'nag': 'swaynag'}, 'python_version': '3.11.3', 'version': '3.50', 'wm_name': 'sway', 'minimum_interval': 0.1, 'click_events': True}
2023-05-10 12:25:39 INFO config file: /dev/null
2023-05-10 12:25:39 ERROR Your configuration file does not list any module to be loaded with the "order" directive. Please try to fix this and reload i3wm (Mod+Shift+R)
2023-05-10 12:25:39 INFO i3status thread mocked with config {'general': {'color_bad': '#FF0000', 'color_degraded': '#FFFF00', 'color_good': '#00FF00', 'color_separator': '#333333', 'colors': True, 'interval': 5, 'output_format': 'i3bar'}, 'py3status': {}, 'order': [], 'on_click': {}, 'i3s_modules': [], 'py3_modules': [], '.module_groups': {}}
2023-05-10 12:25:39 INFO events thread started
2023-05-10 12:25:39 INFO Unix domain socket at /tmp/py3status_uds.271119
2023-05-10 12:25:39 INFO waiting for a connection
2023-05-10 12:25:39 INFO commands thread started
2023-05-10 12:25:39 INFO modules include paths: []
2023-05-10 12:25:39 INFO user_modules={}
2023-05-10 12:25:52 INFO received USR1
2023-05-10 12:25:52 INFO received USR1
2023-05-10 12:25:58 INFO received SIGTERM
2023-05-10 12:25:58 INFO lock set, exiting

Let me know if I can do any other tests or provide data.
Also, I love the project, thanks for all the work on it!

oh, and if anyone comes across this, an easy workaround is using cpulimit to cap it to 1% or so of usage, it works fine.

commented

Does it spawn new py3status instances? I ran into this issue ages ago. My solution was to use a quick script to kill py3status instances before I restart/reload i3.

@lasers It does not. It's a single instance using 100% cpu. It also doesn't happen when the process is spawned by i3, which makes sense, but I'm not sure what's different about how i3 spawns it, compared to awesome/dmenu/etc.

commented

script -qfec "py3status" may or may not help. (Mentioned in PR 2104)

I can confirm that works for me! Back to normal usage. I missed that pr, but this is the same bug mentioned there, if you want to close this as duplicate that's probably appropriate.
Thanks!

Thanks