Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Prevent bar being stopped by using signal other than SIGSTOP #701

Merged
merged 3 commits into from
May 31, 2020
Merged

Prevent bar being stopped by using signal other than SIGSTOP #701

merged 3 commits into from
May 31, 2020

Conversation

ammgws
Copy link
Collaborator

@ammgws ammgws commented May 20, 2020

@GChicha Can you see if this makes any difference with regards to the bar being stopped while hidden?

@ammgws ammgws mentioned this pull request May 20, 2020
Merged
@GChicha
Copy link
Contributor

GChicha commented May 20, 2020

I just checked and it seems to work perfectly. The bar now runs even when hidden.

@ammgws
Copy link
Collaborator Author

ammgws commented May 20, 2020

Now to think of any pitfalls of doing this...

Perhaps we could make it opt-in via a command line argument?

@ammgws ammgws mentioned this pull request May 20, 2020
Closed
@GChicha
Copy link
Contributor

GChicha commented May 20, 2020

I was wondering about it too. Maybe it's only bad when someone was expecting that stopping behavior (like a great computational task when the bar is visible). In my use case, I just hide the status bar for appearance reasons

I was thinking about a flag in the config.toml, but a opt-in via command line seems more versatile.

@ammgws
Prevent bar being stopped by using signal other than SIGSTOP
532235e 
i3 sends SIGSTOP to the bar when it is hidden, which causes the bar to stop
updating. This is done for "power savings" and is not configurable in i3 at
the moment, which inconveniences users of blocks in i3status-rs that are
meant to be running at all times.

Luckily i3 lets us customise the signal it sends, so we can set it to something
other than SIGSTOP to effectively allow non-interrupted of the bar in all
situations.

Fixes greshake#503, greshake#694 and possibly others.
@ammgws ammgws force-pushed the dontstoptilyougetenough branch from b39cbfc to 532235e Compare May 21, 2020 14:10
@ammgws
Copy link
Collaborator Author

ammgws commented May 21, 2020

@GChicha Could you please try with the updated code?

@GChicha
Copy link
Contributor

GChicha commented May 21, 2020

Didn't work for me. Maybe some differences between i3 and sway. I'm getting error reading from status command at the status bar but the i3status-rs is running.

If I run without your argument I'm getting only a raw json at status bar. I have no clue what's going on.

GChicha
GChicha reviewed May 21, 2020
View reviewed changes
src/main.rs Outdated Show resolved Hide resolved
GChicha
GChicha reviewed May 21, 2020
View reviewed changes
src/main.rs Outdated Show resolved Hide resolved
@ammgws ammgws force-pushed the dontstoptilyougetenough branch from e3b6675 to f5830f8 Compare May 21, 2020 23:49
@ammgws
Copy link
Collaborator Author

ammgws commented May 21, 2020 •
edited
Loading

@GChicha Should run now

@GChicha
Copy link
Contributor

GChicha commented May 25, 2020

Oh sorry, I forgot to answer you. Unfortunately I only could run using SIGCHLD, other signals didn't work.

@GChicha
Copy link
Contributor

GChicha commented May 25, 2020

I checked the ps auxf output and seems that even when the bar is visible i3status-rs does not leave the Stopped state (T)

guilher+   53710  0.0  0.0  18684  7476 tty1     S+   19:47   0:00 swaybar -b bar-0
guilher+   53776  0.0  0.0 151824  9356 tty1     Tl+  19:47   0:00  \_ /home/guilherme/.cargo/bin/i3status-rs --never-pause /home/guilherme/.config/i3status/co

@ammgws
Copy link
Collaborator Author

ammgws commented May 26, 2020 •
edited
Loading

OK so TIL the default action for SIGUSR1/2 is to terminate the process...
I will need to either capture the signal or change it to something else that can be used.
Hoever there's also apparently this issue with assigning handlers to SIGUSR1/2...

The SIGUSR1 and SIGUSR2 signals are set aside for you to use any way you want.
They’re useful for simple interprocess communication, if you write a signal handler for them in the program that receives the signal.
The default action is to terminate the process.

@ammgws
Use SIGCONT instead of SIGUSR2
e99bb54 
Since SIGUSR2's default action is to kill the process if there's no handler registered.
@ammgws
Copy link
Collaborator Author

ammgws commented May 28, 2020

@GChicha I just changed it to use SIGCONT instead. When SIGCONT is sent to a running process it is ignored by default, which is what we want. Could you please try again?

In the meantime I may try talk to the i3 devs to at least let us turn this feature off so we don't need to come up with hacks like this.

@ammgws
Copy link
Collaborator Author

ammgws commented May 28, 2020

It appears to be working for me.

@ammgws ammgws mentioned this pull request May 28, 2020
Closed
@GChicha
Copy link
Contributor

GChicha commented May 31, 2020

It looks good now. Thank you for your help. And sorry for the late reply.

@ammgws
Copy link
Collaborator Author

ammgws commented May 31, 2020

I also mentioned this over at i3 and it looks like this PR will end up being the proper solution so I will merge this later on. (Just have to change the signal to '0')

@ammgws ammgws merged commit 4c8a01b into greshake:master May 31, 2020
@ammgws ammgws deleted the dontstoptilyougetenough branch May 31, 2020 08:10
@pedro-nonfree pedro-nonfree mentioned this pull request Jan 21, 2022
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@GChicha GChicha GChicha left review comments

Assignees
No one assigned
Labels
enhancement
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@ammgws @GChicha