Sway reload leaves orphaned i3blocks instances #5584
Comments
|
Duplicate of #4970? |
|
Not exactly the same. In my case each reload produce one sh process and its child process i3blocks. Wherein recent sh process (if it was) ends, but its child i3blocks process becames orphaned. These orphaned i3blocks processes have exactly the same PIDs as before reloading. In addition, if I change config to move to another bar (e.g. waybar) from native swaybar+i3blocks and reload then orphaned i3blocks process stays too. |
|
Hmm. Maybe we're not sending the signal to the process group? |
|
Hello, I can reproduce the multiple i3blocks orphaned instances whenever I refresh my sway config. In addition, I discovered the mouse on-clicks "$BLOCK_BUTTON " does not register the first time swaybar calls i3blocks. I have to exit/restart Sway or refresh the sway config to get the on-click functionality working again (did not have any issues in previous sway versions until now). i3blocks: 1.5-3 |
I also have been getting the multiple i3blocks instances whenever I refresh my sway config since sway 1.3. |
|
I'm having a similar issue with sway 1.5.3, however mine seems to be an exact duplicate of #4970. |
Make the status command a process group leader and change the kill(2)
calls to target the new process group. Signals sent by swaybar will then
be received by both the status command and its children, if any. While
here, check the result of fork(2).
Without this, children spawned by the status command may not receive the
signals sent by swaybar. As a result, these children may be orphaned on
reload.
The issue could be shown by setting the bar to
bar {
status_command i3status | tee /tmp/i3status.out
}
which would leave orphaned processes for each reload of sway
$ ps o pid,ppid,cmd | grep i3status | grep -v grep
43633 43624 sh -c i3status | tee /tmp/i3status.out
43634 43633 i3status
43635 43633 tee /tmp/i3status.out
$ swaymsg reload
$ ps o pid,ppid,cmd | grep i3status | grep -v grep
43634 1 i3status
43635 1 tee /tmp/i3status.out
43801 43788 sh -c i3status | tee /tmp/i3status.out
43802 43801 i3status
43803 43801 tee /tmp/i3status.out
This fixes swaywm#5584.
Make the status command a process group leader and change the kill(2)
calls to target the new process group. Signals sent by swaybar will then
be received by both the status command and its children, if any. While
here, check the result of fork(2).
Without this, children spawned by the status command may not receive the
signals sent by swaybar. As a result, these children may be orphaned on
reload.
The issue could be shown by setting the bar to
bar {
status_command i3status | tee /tmp/i3status.out
}
which would leave orphaned processes for each reload of sway
$ ps o pid,ppid,cmd | grep i3status | grep -v grep
43633 43624 sh -c i3status | tee /tmp/i3status.out
43634 43633 i3status
43635 43633 tee /tmp/i3status.out
$ swaymsg reload
$ ps o pid,ppid,cmd | grep i3status | grep -v grep
43634 1 i3status
43635 1 tee /tmp/i3status.out
43801 43788 sh -c i3status | tee /tmp/i3status.out
43802 43801 i3status
43803 43801 tee /tmp/i3status.out
This fixes #5584.
Make the status command a process group leader and change the kill(2)
calls to target the new process group. Signals sent by swaybar will then
be received by both the status command and its children, if any. While
here, check the result of fork(2).
Without this, children spawned by the status command may not receive the
signals sent by swaybar. As a result, these children may be orphaned on
reload.
The issue could be shown by setting the bar to
bar {
status_command i3status | tee /tmp/i3status.out
}
which would leave orphaned processes for each reload of sway
$ ps o pid,ppid,cmd | grep i3status | grep -v grep
43633 43624 sh -c i3status | tee /tmp/i3status.out
43634 43633 i3status
43635 43633 tee /tmp/i3status.out
$ swaymsg reload
$ ps o pid,ppid,cmd | grep i3status | grep -v grep
43634 1 i3status
43635 1 tee /tmp/i3status.out
43801 43788 sh -c i3status | tee /tmp/i3status.out
43802 43801 i3status
43803 43801 tee /tmp/i3status.out
This fixes swaywm#5584.
If I reload sway, recent i3block instance becomes orphaned and thus over time with frequent reloads there are too many of them. I checked i3 and it doesn't do that.
Sway: 1.5.2
i3blocks: 1.5.2
Kernel: x86_64 Linux 5.7.10_1
OS: Void Linux
The text was updated successfully, but these errors were encountered: