Skip to content

block: Keep RTMIN through RTMAX signals blocked in child#454

Open
nfraprado wants to merge 1 commit into
vivien:masterfrom
nfraprado:child_sig_block_fix
Open

block: Keep RTMIN through RTMAX signals blocked in child#454
nfraprado wants to merge 1 commit into
vivien:masterfrom
nfraprado:child_sig_block_fix

Conversation

@nfraprado

@nfraprado nfraprado commented Oct 17, 2021

Copy link
Copy Markdown

When a child process is forked for a block, it has the signals RTMIN
through RTMAX blocked by default, but block_child_sig() unblocks all
signals including these.

Unblocking these signals is troublesome given that:

  • The easiest way to signal i3blocks for an update is through pkill (as
    shown at https://vivien.github.io/i3blocks/#_signal ). But pkill sends
    a signal to all processes with that name, which includes the child
    fork.
  • Since those signals are unblocked, but not handled, in the child, when
    one of them is sent to i3blocks, and while it is being handled in
    the child process, another one is sent, the child process will also
    receive the signal and therefore crash since it is unhandled.

If we assume that the RTMIN through RTMAX signals are uncommon enough
that they won't be used in the child process, the solution is as easy as
keeping these signals blocked for the child process.

Fixes #455.

When a child process is forked for a block, it has the signals RTMIN
through RTMAX blocked by default, but block_child_sig() unblocks all
signals including these.

Unblocking these signals is troublesome given that:
- The easiest way to signal i3blocks for an update is through pkill (as
  shown at https://vivien.github.io/i3blocks/#_signal ). But pkill sends
  a signal to all processes with that name, which includes the child
  fork.
- Since those signals are unblocked, but not handled, in the child, when
  one of them is sent to i3blocks, and while it is being handled in
  the child process, another one is sent, the child process will also
  receive the signal and therefore crash since it is unhandled.

If we assume that the RTMIN through RTMAX signals are uncommon enough
that they won't be used in the child process, the solution is as easy as
keeping these signals blocked for the child process.
vivien added a commit that referenced this pull request Jan 13, 2023
Now that the original signal mask from the parent process is stored
in bar->sigset, use it to restore the signal set in child processes
instead of unblocking them all.

Refs #454
Closes #455
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Two consecutive signals crash block until next timeout

1 participant