i3status/blocks bar hangs up from time to time

[unera]

From time to time i3status/blocks bar hangs up.
I think the bar hangs often after suspend/resume. If CPU usage reaches 100% the bar hangs up, too.

Example: Now is 10:57, but the bar did hang at 10:39:

PS:
Binary i3 version: 4.13 (2016-11-08) © 2009 Michael Stapelberg and contributors
Running i3 version: 4.13 (2016-11-08) (pid 5895)o abort…)
Loaded i3 config: /home/unera/.i3/config (Last modified: Ср 07 мар 2018 21:56:48, 3329319 seconds ago)

The i3 binary you just called: /usr/bin/i3
The i3 binary you are running: i3

https://logs.i3wm.org/logs/5703935746637824.bz2

[i3bot]

Sorry, we can only support the latest major version. Please upgrade from 4.13 to 4.15, verify the bug still exists, and re-open this issue.

[unera]

Please reopen the ticket. 4.15 version hangs up, too:

logfile: https://logs.i3wm.org/logs/5660082654150656.bz2

$ i3 --moreversion 2>&- || i3 --version
Binary i3 version: 4.15 (2018-03-10) © 2009 Michael Stapelberg and contributors
Running i3 version: 4.15 (2018-03-10) (pid 5895)o abort…)
Loaded i3 config: /home/unera/.i3/config (Last modified: Ср 07 мар 2018 21:56:48, 3330659 seconds ago)

The i3 binary you just called: /usr/bin/i3
The i3 binary you are running: i3

[unera]

$ cat .i3/blocks
# i3blocks config file
#
# Please see man i3blocks for a complete reference!
# The man page is also hosted at http://vivien.github.io/i3blocks
#
# List of valid properties:
#
# align
# color
# command
# full_text
# instance
# interval
# label
# min_width
# name
# separator
# separator_block_width
# short_text
# signal
# urgent

# Global properties
separator_block_width=15

[ticket]
command=test -r ~/.ticket && cat ~/.ticket
interval=1
color=#7777FF

[wifi]
instance=wlan0
interval=2
command=/usr/share/i3blocks/wifi
label=WiFi
min_width='100%'
separator=false

[wifi]
instance=wlp1s0
interval=2
command=/usr/share/i3blocks/wifi
label=W
min_width='100%'
separator=false

[wifi-name]
interval=2
command=sudo wpa_cli status|grep -i ^ssid=|sed 's/^ssid=//i'

[iface]
instance=wlan0
interval=2
command=/usr/share/i3blocks/iface
label=IP

[volume]
label=♪
instance=Master
command=/usr/share/i3blocks/volume
interval=1
signal=10

[temperature]
label=t
interval=10
command=/usr/share/i3blocks/temperature
separator=false

[cpu]
label=CPU
command=/usr/share/i3blocks/cpu_usage -w 30 -c 70
interval=2
separator=false
min_width=' 100.00% '
align=right

[battery]
label=⚡
command=/usr/share/i3blocks/battery
interval=30

[time]
command=date +'   %A, %d %b %H:%M:%S  '
interval=1
color=#8888ff

[lock]
command=bash ~/.scripts/lockscreen-bar
interval=once
color=#ee7777

[LANG]
command=~/.scripts/i3block-layout
interval=1

[Airblader]

You said it also happens with i3status. Does it happen with the default i3status config? If not, which config are you using here?

I'm not too concerned with i3blocks causing this. i3blocks has open issues regarding freezes.

[unera]

You said it also happens with i3status

time ago I opened the same ticket #1904 (i3 4.10)

I used i3status then.

The ticket was fixed and I used 4.10.
Last week I upgraded i3 to 4.13 (Debian/stable), then (Now) to 4.15.

statusbar hangs up again.

The bar often hangs after suspend/resume, but from time to time hangs if CPU usage reaches 100%.
Alt-Shift-r (i3 restart) solve the problem.

PS: I switched my i3 to i3status, https://logs.i3wm.org/logs/5731644862365696.bz2

the bar hangs, too:

my i3status config:

# i3status configuration file.
# see "man i3status" for documentation.

# It is important that this file is edited as UTF-8.
# The following line should contain a sharp s:
# ß
# If the above line is not correctly displayed, fix your editor first!

general {
        colors = true
        interval = 1
        output_format = "i3bar"
}

order += "wireless wlan0"
order += "wireless wlan1"
order += "run_watch DHCP"
order += "battery 0"
# order += "load"
order += "cpu_usage"
order += "volume_master"
order += "tztime local"

cpu_usage {
	format = "%usage"
}

wireless wlan0 {
        format_up = "W: (%quality at %essid) %ip"
        format_down = ""
}

wireless wlan1 {
        format_up = "W: (%quality at %essid) %ip"
        format_down = ""
}

battery 0 {
        format = "%status %percentage %remaining"
}

run_watch DHCP {
        pidfile = "/var/run/dhclient*.pid"
}

tztime local {
        format = "  %A, %d %b %H:%M:%S   "
}

load {
        format = "%1min"
}

disk "/" {
        format = "%avail"
}

volume master {
	format = "♪ %volume"
	format_muted = "♪ muted (%volume)"
	device = "default"
	mixer = "Master"
	mixer_idx = 0
}
volume master {
	format = "♪ %volume"
	format_muted = "♪ muted (%volume)"
	device = "default"
	mixer = "PCM"
	mixer_idx = 0
}

[Airblader]

Thanks for the confirmation that you can reproduce it with i3status, too.

[orestisfl]

Does your i3bar update correctly? ie, do the workspace buttons update?

[unera]

Does your i3bar update correctly? ie, do the workspace buttons update?

While i3bar hangs, I can switch (by mouse and by keyword) through workspaces, I can watch systray icons (ex. telegram icon on screenshot).

Only bar (i3block/i3status) hangs until Alt-Shift-r (i3 restart).

[orestisfl]

Can you run i3status from the command line and see if you can get it to freeze?

[unera]

Can you run i3status from the command line and see if you can get it to freeze?

I run 2 terminals:

1. i3status -c .i3/status
2. i3blocks

Then suspend/resume my laptop until i3bar hangs.

i3status/i3blocks in console continue work, but i3blocks in i3bar hangs.

See screenshot

workspace buttons, tray icons are clickable.

[unera]

Is there any chanсe the somebody will pay attention with my ticket?

[orestisfl]

I did pay attention to your ticket and regularly check my bar for hangs. Unfortunately, these issues are not easy to reproduce. If you have any idea why this is happening you are more than welcome to write a patch.

[unera]

I did pay attention to your ticket and regularly check my bar for hangs. Unfortunately, these issues are not easy to reproduce.

The problem is well reproducible on 3 (three) my computers.

I use:

• Debian/stable,
• sysvint (not systemd),
• uswsusp,
• laptop-mode-tools
• acpi

each pm-suspend start has ~30% chance to see the bug.

[unera]

Also version 4.10 never hangs.

[unera]

Additional information:

Now my i3block has hung up.

I looked through ps ax, found the situation:

11938 ?        T      0:00 /bin/sh -c i3blocks -c ~/.i3/blocks
11939 ?        T      0:02 i3blocks -c /home/unera/.i3/blocks

then I did:

kill -CONT 11939

And my i3block began work without i3 restart.

So: i3 hangs because it received SIGSTOP, but SIGCONT was lost somewhere.

[unera]

Hi!

I've just installed Debian/i3 to new laptop and the bug is reproducible, too.

[unera]

Additional information:

statusbar hangs up, too if:

1. run i3 with i3status
2. change system time (one-two hours back)

[stapelberg]

SIGSTOP/SIGCONT are only sent when i3bar goes into hide mode (so that the child process doesn’t unnecessarily compute updates which are invisible anyway).

Are you using i3bar’s hide mode? If yes, can you try going into hide mode and back to bar mode when you have the problem and see if that gets the process unstuck? If no, can you run strace -f -p $(pidof i3bar) -y -o /tmp/st -s 2048 and toggle hide mode/bar mode again, then provide the contents of /tmp/st please?

statusbar hangs up, too if:

1. run i3 with i3status
2. change system time (one-two hours back)

That’s likely a separate problem. Can you file a separate issue for that please?

[szborows]

I confirm what @unera reports: it also happens on my machine, usually after suspending it. I'm using systemd. Sending SIGCONT to the process helps too.

Maybe the problem happens only when you go fullscreen and then suspend?

[szborows]

I was able to reproduce it with following scenario:

1. Switch to single display (laptop one)
2. Go fullscreen
3. Suspend
4. Un-suspend (restore?)
5. Before switching back to non-fullscreen mode switch desktop configuration (I'm using xrandr for this)
6. The process is stopped forever now. Even going back to non-fullscreen mode doesn't help.

EDIT: this is how output of my strace run looks like (IP addresses replaced with Xes)

5854  write(1<pipe:[40605]>, ",[{\"full_text\":\"\"},{\"\":\"\",\"full_text\":\"\342\231\252 20%\",\"name\":\"volume\",\"instance\":\"Master\",\"separator_block_width\":15,\"markup\":\"none\"},{\"\":\"\",\"full_text\":\"MEM 9.4G/15.6G (61%)\",\"short_text\":\"61%\",\"name\":\"memory\",\"separator\":false,\"separator_block_width\":15,\"markup\":\"none\"},{\"\":\"\",\"full_text\":\"HOME 9.8G\",\"short_text\":\"9.8G\",\"color\":\"#FF0000\",\"name\":\"disk\",\"separator_block_width\":15,\"markup\":\"none\"},{\"\":\"\",\"full_text\":\"W: X.X.X.X\",\"short_text\":\"X.X.X.X\",\"color\":\"#00FF00\",\"name\":\"iface\",\"instance\":\"wlp2s0\",\"separator\":false,\"separator_block_width\":15,\"markup\":\"none\"},{\"\":\"\",\"full_text\":\"E: down\",\"short_text\":\"down\",\"color\":\"#FF0000\",\"name\":\"iface\",\"instance\":\"eth0\",\"separator\":false,\"separator_block_width\":15,\"markup\":\"none\"},{\"\":\"\",\"full_text\":\"BAT 98% CHR\",\"short_text\":\"98% CHR\",\"name\":\"battery\",\"separator_block_width\":15,\"markup\":\"none\"},{\"\":\"\",\"full_text\":\"2018-11-06 09:52:09\",\"name\":\"time\",\"separator_block_width\":15,\"markup\":\"none\"}]\n", 951) = 951
5854  rt_sigtimedwait([INT USR1 USR2 ALRM TERM CHLD IO RT_2 RT_3 RT_4 RT_5 RT_6 RT_7 RT_8 RT_9 RT_10 RT_11 RT_12 RT_13 RT_14 RT_15 RT_16 RT_17 RT_18 RT_19 RT_20 RT_21 RT_22 RT_23 RT_24 RT_25 RT_26 RT_27 RT_28 RT_29 RT_30 RT_31 RT_32], 0x7fff569f3260, NULL, 8) = -1 EINTR (Interrupted system call)
5854  --- SIGSTOP {si_signo=SIGSTOP, si_code=SI_USER, si_pid=5849, si_uid=1000} ---
5854  --- stopped by SIGSTOP ---

[lasers]

Py3status have the same problem. See ultrabug/py3status#941.

[steinex]

Same issue for me. I use unredir-if-possible = true in compton.conf. When compton unredirects e.g. due to opening a fullscreen video, i3bar sends SIGTSTP. However, sometimes it never sends the SIGCONT and i3status / py3status stop to update.

[Alexander--]

Any news on when this will be fixed?

[stapelberg]

Once @dfoxfranke (or somebody else) moves pull request #3761 forward.

If you’re in a hurry, I recommend you build your own version of i3 with that pull request applied.

[Alexander--]

I don't like this feature and how it is implemented.

Signals aren't reliable form of communication. More importantly, the possibility of erroneously suspending a status bar really isn't worth the hassle of having that feature.

To makes matters worse, i3bar does not offer a way to opt-out of suspension. A process can't intercept SIGSTOP, so status bar implementations that expect to run at all times are screwed.

You are right, I am "in hurry", so I can send a pull request, that removes the code, sending SIGSTOP/SIGCONT. I don't want to take over #3761 and invest effort in fixing this feature only for it to get broken again later (and breaking it is apparently too easy).

[stapelberg]

You are right, I am "in hurry", so I can send a pull request, that removes the code, sending SIGSTOP/SIGCONT.

I’m not convinced that removing the code is the best option.

If you don’t want to contribute a proper fix, that’s okay. But we definitely want to try fixing this issue before we remove the feature.

[Alexander--]

I’m not convinced that removing the code is the best option.

Are you sure, that you aren't overestimating practical usefulness of SIGSTOP?

When people expect to preserve charge of notebook's battery, they suspend. This is more reliable that SIGSTOP and actually shuts down all processes, that can cause power drain.

Saving power when lid is closed (without suspending!) sounds like somewhat obscure use case, that comes in play once in a while, but does not make big difference. Yet you are triggering the behaviour in question for all devices — even ones without a battery. If you have concrete concerns about power use of i3status, wouldn't it be better to fix the specific problems with it? That would actually decrease power use for everyone and at all times — not just when lid is closed or monitor is shut down.

[stapelberg]

Saving power when lid is closed (without suspending!) sounds like somewhat obscure use case

I agree, but that’s not the use-case for the SIGSTOP feature. Instead, the following two scenarios were the main motivation:

1. Running i3bar in hide mode (see https://i3wm.org/docs/userguide.html#_display_mode) defaults to not displaying the status bar, and only displays it when you press the modifier key.
2. While in fullscreen mode (e.g. reading a scientific paper), the bar is invisible, too.

[Airblader]

I don't have strong opinions, but we could also just stop the process and spawn a new one rather than suspend(?)

[Alexander--]

I don't have strong opinions, but we could also just stop the process and spawn a new one rather than suspend(?)

This bug report isn't about suspension method.

The problem is: i3bar sometimes suspends i3status and never resumes it again. The method does not matter, because the status bar isn't being resumed at all.

[neocturne]

I've tried #3761 and it doesn't fix the issue - especially when using a compositing manager, i3status is pretty much stuck forever after changing display configuration, unless I SIGCONT it manually.

I would prefer a simple way to disable the SIGSTOP feature completely, as it's useless for me. Other applications I have always running use several magnitudes more CPU / battery in idle than i3bar/i3status ...

[rvalieris]

I ran into a similar issue, and I managed to turn off sig stop/count by setting the stop_signal/cont_signal options of the i3bar protocol: https://i3wm.org/docs/i3bar-protocol.html
I just set both signals to SIGUSR1 (10).
not sure how to set this on i3status however.. (I have my on custom i3bar script).

[indradhanush]

I was using i3status and encountered this problem. I recently moved to i3status-rust and I see the same problem. So maybe this is an independent issue of both i3status and i3status-rust. Also I'm on kernel 5.5.13 running Arch Linux.

My i3 version is 4.18.

[Alexander--]

@indradhanush

This is upstream bug in i3. All i3 status bars, no matter the implementation language, are equally vulnerable to it. There is nothing that can be done about it by i3status or it's alternatives.

[orestisfl]

Please see if #3996 fixes your issue

[Alexander--]

@orestisfl

Thanks for fixing (?) this. In case this issue resurfaces again, is it possible to somehow make it more obvious, that status bar is hung and the status line isn't being updated?

Can i3 somehow fill the window of suspended status bar with solid color until it is repainted?

[orestisfl]

I don't see the value in going out of our way to implement that. I can put some debug log messages though.

[ammgws]

@orestisfl
If I have understood correctly, #3996 does not solve the issue of the bar being paused when hidden, does it?

[orestisfl]

The bar is still paused, just continued more liberally