gpakosz / .tmux

🇫🇷 Oh my tmux! My self-contained, pretty & versatile tmux configuration made with ❤️
MIT License
21.79k stars 3.36k forks source link

`#{loadavg}` ignores `status-interval` #622

Closed sylph1o closed 1 year ago

sylph1o commented 1 year ago

#{loadavg} always refreshes at the same rate, roughly every 5 seconds. I have left the value of status-interval to its default set in tmux.conf: 10 (seconds). Even if I run tmux set -g status-interval 1000, the refresh is unchanged.

I have included #{loadavg} in my status bar as follows

tmux_conf_theme_status_right="#{?client_prefix,#{prefix}, }#{mouse}#{synchronized}#{pairing}#{loadavg} , #{?battery_status,#{battery_status},}#{?battery_bar, #{battery_bar},}#{?battery_percentage, #{battery_percentage},} | %m-%d | %R "

My tmux.conf is unchanged, all my changes are in tmux.conf.local. I am using tmux 3.3 on Linux. Does anyone have a hint on how to troubleshoot this?

Thanks in advance :pray:

gpakosz commented 1 year ago

Hello @sylph1o 👋

After changing status-interval, you need to reload the configuration with prefix+r for Oh my tmux! to adjust

sylph1o commented 1 year ago

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?

gpakosz commented 1 year ago

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?

sylph1o commented 1 year ago

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:

  1. kill manually all the processes monitoring loadavg;
  2. set a new value for status-interval in tmux.conf.local (e.g. set -g status-interval 20);
  3. reload the configuration, and observe the expected refresh rate.

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 🙏

gpakosz commented 1 year ago

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 🙏

❤️

sylph1o commented 1 year ago

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! 🙏

gpakosz commented 1 year ago

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:

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.

gpakosz commented 1 year ago

Hello @sylph1o 👋 Did you have the chance to test the gh-200+221+439+586 branch?

sylph1o commented 1 year ago

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