If I launch a graphical program from a block and restart i3, the program dies even if disowned.

[mutageneral]

If I launch a graphical program by clicking on the bar, and then restart i3 doing $mod+shift+r (or i3-msg restart), the program dies, but its window stays open, which become pitch black with an icon in the middle. This happens even if using nohup, & and redirecting to /dev/null all at once.

When I run xprop on the zombie window, I get way less info than usual, proving that it is dead:

_NET_WM_STATE(ATOM) = 
_NET_WM_DESKTOP(CARDINAL) = 6
WM_STATE(WM_STATE):
                window state: Normal
                icon window: 0x0
_NET_WM_NAME(UTF8_STRING) = "i3blocks : ping — Konsole"
WM_HINTS(WM_HINTS):
                Client accepts input or input focus: False
                bitmap id # of mask for icon: 0x0
                window id # to use for icon: 0x6ee301e8
                starting position for icon: 21930, 248
                window id # of group leader: 0x6fb76190
                The urgency hint bit is set

This does not happen to other windows or to the program if launched from a terminal with nohup and & and then close the terminal.

I wish that windows launched from an i3blocks could survive the reload of i3. Using i3-msg exec followed by the command I want to launch can be used to circumvent this issue, but I find it to be an ugly fix that makes my blocks less portable.

[bhepple]

Try closing the stdin, out & err of the launched program eg:

 setsid "$app" </dev/null &>/dev/null &

[mutageneral]

setsid -f seems to fix the problem just like i3-msg exec dose. The rest doesn't affect this specific bug. Not having >/dev/null makes the bar freeze after the program was launched, but that is irrelevant here. I guess I will be using setsid -f from now on, but it isn't as portable of a solution that I would have liked (the command is not on BSD as far as I know).