i3blocks freezes when clicking clickable blocklet, while having other blocklets with fish scripts as command

[Maxr1998]

When using e.g. the example blocklet from the README:

[clickme]
full_text=Click me!
command=echo button=$BLOCK_BUTTON x=$BLOCK_X y=$BLOCK_Y
min_width=button=1 x=1366 y=768
align=left

Here's the journal log from right before the click happens.

Feb 08 10:12:51 xps13 i3-gnome.desktop[21752]: DEBUG click_parse:65: parsed click: name= instance= button= x= y=
Feb 08 10:12:51 xps13 i3-gnome.desktop[21752]: DEBUG click_parse:65: parsed click: name=button instance= button=button x=1206 y=5
Feb 08 10:12:51 xps13 i3-gnome.desktop[21752]: DEBUG bar_poll_clicked:62: [button] clicked
Feb 08 10:12:51 xps13 i3-gnome.desktop[21752]: DEBUG block_spawn:293: [button] forked child 26077 at 1518081171

And then.. it freezes (values don't get updated anymore, e.g. time blocklet stops working.

Here's the full journal after restarting i3:
https://hastebin.com/mewinezoco.vbs

[jolange]

Which i3blocks version do you use?

I recently encountered exactly the same issue and found that this was caused by a single block (an own script). If I disable that one, everything is fine. I did not yet figure out what the actual problem is, though.

Could you check if you can verify that a single block is causing this?

[Maxr1998]

My version is 1.4.
You're right, when I only have a single, clickable block in my config, it actually works. Trying to find out now which block causes the bug.

[Maxr1998]

Ok, it seems it doesn't like my referenced fish scripts in two blocklets. Switching the shebang to bash does the trick. Still weird why fish isn't supported.

[Jab2870]

I have the same problem but don't have any fish scripts. For me, removing this block solves the problem. Not sure why though.

[homeServerUpdates]
interval=300
command=~/.dotfiles/i3/blocks/homeServerUpdates
label=Home Server Updates

Here is my shell script

#!/usr/bin/sh

count=$(ssh homeServer -t checkupdates 2> /dev/null | wc -l )
if [ "$count" = "0" ]; then
	echo ""
	echo ""
	echo ""
else
	echo $count
	echo $count
	if [ "$count" -gt "5" ]; then
		echo "#FFOOOO"
	else
		echo "#FF8000"
	fi
fi

Edit: It was pointed out that changing to bash might help, this didn't fix it for me.

[Maxr1998]

Doesn't echo print a newline by default? I think i3blocks can't handle more than one line. Try to use echo -n and a normal echo at the end.

[Jab2870]

Thanks, unfortunately that didn't work.

FYI, i3 blocks will use the first 3 lines of stdout.

http://vivien.github.io/i3blocks/#COMMAND

COMMAND
The value of the command key will be passed and executed as is by a shell.

The standard output of the command line is used to update the block content. Each non-empty line of the output will overwrite the corresponding property:

full_text
short_text
color
For example, this script sets the full_text in blue but no short_text:

echo "Here's my label"
echo
echo #0000FF
If the command line returns 0 or 33, the block is updated. Otherwise, it is considered a failure and the first line (if any) is still displayed. Note that stderr is ignored. A return code of 33 will set the urgent flag to true.

[Maxr1998]

Ah, I see. Didn't know that, thanks. Sorry that I couldn't be of any help..

[vivien]

Guys do you still have an issue? Especially with latest i3blocks master? I have trouble identifying your issue here. If you still have an issue, are you able to provide me a minimal example so that I can reproduce it? Thank you!

P.S.: @Jab2870 I like the i3/blocks/foo path to yours blocklets ;-)

[Maxr1998]

@vivien Yes, still happens with i3blocks-git that I updated, built, and installed today (thus latest master). An example blocklet that breaks i3blocks in the config from the first post is

#!/usr/bin/fish
cat /proc/cpuinfo | grep MHz | awk '
BEGIN { a = 0 }
{
    if ($4 > a) {
        a = $4
    }
} 

The breaking blocklet itself doesn't have to be clickable, and it's completely irrelevant which block is clicked.
It works perfectly fine when replacing #!/usr/bin/fish with #!/bin/bash.

What I suspect is that the passed click variables can't be parsed/computed in fish, and the process freezes..

[vivien]

This script doesn't print anything. Please provide a working example as well as the corresponding block config. Thank you!

[Maxr1998]

Seems to be a different cpuinfo format for you. I will post both requested things tomorrow.

[Jab2870]

@vivien I am still getting the issue.

My working example is above. I have installed i3blocks-git from the aur. I assume it is the newest version because all of my labels have disappeared. Is this to be expected? I can open a new issue if not.

[vivien]

OK I can reproduce the issue. For some reasons, once processes like fish or ssh are forked, the parent's stdin is messed up, making it blocking again (regardless O_NONBLOCK). So i3blocks gets stuck on click processing.

command=fish -c date # mess stdin
command=ssh foo date # mess stdin
command=bash -c date # works fine
interval=once

I'm investigating this.

[Maxr1998]

Ok, glad you could reproduce it. Hope you're able to fix it soon. fish is sometimes a little weird, but the auto-complete and history is just perfect for me..

[vivien]

This problem came from the duplicated standard input shared between the parent (i3blocks) and the child (e.g. fish -c date). For some reason that I cannot explain yet, a child process may monopolized the parent standard input (even though the child process exited) and making it blocking again.

To fix this the best practice is to close and reopen a dummy standard input in the child process. The commit a586a34 does that. Another solution is to close stdin on exec, as commit d376075 does. Both solutions can coexist and are implemented now.

[Jab2870]

This is sorted for me, thanks for fixing this.

[DonPiotr]

Thanks, i had this problem with ruby scripts
After i read this discussion, i set in my conf file:

command=~/.scripts/statusbar/$BLOCK_NAME </dev/null

It's work for me.