Closed sylph1o closed 1 year ago
Hello @sylph1o 👋
After changing status-interval
, you need to reload the configuration with prefix+r
for Oh my tmux! to adjust
Hello @gpakosz and thank you for the quick answer :slightly_smiling_face:
I was running tmux set -g status-interval
directly from the command line. I have also tried editing the value of status-interval
in tmux.conf
and reloading. Either way, the refresh rate of loadavg
remains roughly 5 seconds, even with status-interval
set to 1 or to 1000.
I always confirm that the value is set correctly by running tmux show -g status-interval
in my terminal. Although I don't think it matters, I also checked that tmux show status-interval
returned nothing.
Any idea on how I can get better insight into the cause of this behaviour?
If you're running tmux 3.3
, you can look at the output of
$ ps aux | grep 'cut -c3-' | grep 'loadavg'
You'll see a sleep xx;
command and it takes the value of status-interval
at the time the configuration is parsed.
With tmux 3.2+
there's a background job that refreshes the @loadavg
variable. By default every 10
seconds as it's the default value of status-inverval
. Then, when refreshing the status line, tmux displays the value of this variable (see the output of tmux show -gv status-right
).
What are you trying to achieve?
Thank you for the advice, that lead to the solution.
For one thing, it made me realise that simply running tmux set -g status-interval
from the terminal was pointless, since that value was only read when the process monitoring the load was started. Only changing the configuration file then reloading it could have an effect (which I tried as well).
Secondly, I actually found many such processes, with different sleep
arguments ranging from 1 to 10000. I suppose that a new process was spawned every time that I reloaded the configuration. This explains why I did not seem to be able to lower the refresh rate. If anything, I am surprised that it was only around 5 seconds, given that I had one process with sleep 1
(there seem to be a minimum interval for some reason). I also surmise that reloading the configuration (even without changing status-interval
) would accidentally lower the refresh interval of loadavg
by spawning a second monitoring process, likely shifted from the first one by a few seconds. That is probably what caused the original issue that I observed, since I had been editing and reloading my configuration at the time.
In the end the solution was:
loadavg
;status-interval
in tmux.conf.local
(e.g. set -g status-interval 20
);What are you trying to achieve?
For the background story, my original intention was to make loadavg
less distracting: it kept blinking in my status bar, and that was annoying me. I eventually discovered that this was caused by the blink
attribute of the element immediately to its left, and fixed it by changing the order to have an element explicitly not blinking to its left:
tmux_conf_theme_status_right="[...]#{pairing}#{synchronized}#{loadavg}[...]"
[...]
tmux_conf_theme_synchronized_attr="blink"
[...]
tmux_conf_theme_pairing_attr="none"
fixed by swapping pairing
and synchronized
:
tmux_conf_theme_status_right="[...]#{synchronized}#{pairing}#{loadavg}[...]"
[...]
tmux_conf_theme_synchronized_attr="blink"
[...]
tmux_conf_theme_pairing_attr="none"
However, the value of loadavg
was still changing too often for my taste. I understand now that my multiple reloading of the configuration had spawned more monitoring processes and therefore caused it to be refreshed every 4 or 5 seconds (and I was less tolerant at that point). Therefore, I tried to change it, realised none of my attempts had any effect and decided to open this issue to ask for help.
My issue (which I caused myself) is solved thanks to your help @gpakosz. Thank you very much! Not only this, but thank you as well for this awesome configuration which made me love tmux
🙏
Thanks for the answer @sylph1o
Secondly, I actually found many such processes, with different sleep arguments ranging from 1 to 10000. I suppose that a new process was spawned every time that I reloaded the configuration.
However, reloading the configuration should have killed the previous ones.
See # _pkillf 'cut -c3- ~/\.tmux\.conf \| sh -s _loadavg'
in .tmux.conf
. I have an upcoming branch that makes it more robust. Still you please paste the output of ps aux | grep
-c3-| grep 'loadavg'
?
I eventually discovered that this was caused by the blink attribute of the element immediately to its left
Hmm I see, I guess there's room for improvement by letting .tmux.conf
insert #[none]
attributes when replacing the variables
Thank you very much! Not only this, but thank you as well for this awesome configuration which made me love tmux 🙏
❤️
Here is the output:
<my username> 2773 0.0 0.0 8064 4252 ? S 00:25 0:01 sh -c trap '[ -n "$sleep_pid" ] && kill -9 $sleep_pid; exit 0' TERM; while [ x"$(tmux -S '/tmp/tmux-1000/default' display -p '#{pid}')" = x"2453" ]; do nice cut -c3- ~/.config/tmux/tmux.conf | sh -s _loadavg; sleep 20 & sleep_pid=$!; wait $sleep_pid; sleep_pid=; done
I can confirm that this process is not killed when the configuration is reloaded. Another – identical one – is spawned.
Your quote of the call to _pkillf
lead me to the solution: it was my own fault, again.
I organise my $HOME
following the XDG base directory specification, and therefore my tmux
configuration resides in ~/.config/tmux/
(i.e. $XDG_CONFIG_HOME
for me). To adapt oh-my-tmux, I run a simple substitution with sed
everytime I update:
sed -i 's_~/\.tmux_~/\.config/tmux/tmux_g' ~/config/tmux/tmux.conf
Your quote made me realise that I had been careless and overlooked that some characters may be escaped. It's even surprising that I have not run into problems before now.
After a more careful examination of the configuration file, I think I have a comprehensive substitution. I write the script below, in case it would be useful in the future to anyone who would find this thread (e.g. by searching 'XDG' in this repository). Playing with several layers of escaping is always terrific fun, but sometimes life is just too short.
#!/usr/bin/env sh
# Replace all occurences of '~/.tmux.conf' with '~/.config/tmux/tmux.conf',
# accounting for '.' or '/' being escaped.
# 1. Both '.' and '/' escaped: '~\/\.tmux\.conf' -> '~\/\.config\/tmux\/tmux\.conf'
sed -i 's_~\\/\\\.tmux_~\\/\\\.config\\/tmux\\/tmux_g' "$HOME/.config/tmux/tmux.conf"
# 2. Only '/' escaped: '~\/.tmux.conf' -> '~\/.config\/tmux\/tmux.conf'
sed -i 's_~\\/\.tmux_~\\/\.config\\/tmux\\/tmux_g' "$HOME/.config/tmux/tmux.conf"
# 3. Only '.' escaped: '~/\.tmux\.conf' -> '~/\.config/tmux/tmux\.conf'
sed -i 's_~/\\\.tmux_~/\\\.config/tmux/tmux_g' "$HOME/.config/tmux/tmux.conf"
# 4. No character escaped: '~/.tmux.conf' -> '~/.config/tmux/tmux.conf'
sed -i 's_~/\.tmux_~/\.config/tmux/tmux_g' "$HOME/.config/tmux/tmux.conf"
After performing the substitution above, I confirm that reloading the configuration kills any previous monitoring process I had (i.e. load and battery).
This thread is full of self-inflicted bugs. Thanks again for the support! 🙏
I organise my
$HOME
following the XDG base directory specification, and therefore mytmux
configuration resides in~/.config/tmux/
(i.e.$XDG_CONFIG_HOME
for me). To adapt oh-my-tmux, I run a simple substitution withsed
everytime I update:
In that case can you please try the gh-200+221+439+586
branch and stop modifying tmux.conf
?
It supports the XDG base directory specification and I'm looking for more testers.
Hello @sylph1o 👋
Did you have the chance to test the gh-200+221+439+586
branch?
Yes, I have tested it and I finally have something to report! I'll open a new issue right now.
P.S. This is #624
#{loadavg}
always refreshes at the same rate, roughly every 5 seconds. I have left the value ofstatus-interval
to its default set intmux.conf
: 10 (seconds). Even if I runtmux set -g status-interval 1000
, the refresh is unchanged.I have included
#{loadavg}
in my status bar as followsMy
tmux.conf
is unchanged, all my changes are intmux.conf.local
. I am using tmux 3.3 on Linux. Does anyone have a hint on how to troubleshoot this?Thanks in advance :pray: