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.

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

Improve signal/interrupt handling #1803

Closed
wants to merge 13 commits into from

Conversation

davoclavo
Copy link

@davoclavo davoclavo commented Dec 30, 2023

Howdy! I took a stab to fix multiple issues related to signal handling - and address some improvements on the current signal/interruption handler

#1558
#1560
#1781

A summary of the changes:

  • Renamed the interrupt_handler to signal_handler to make it more explicit that any arbitrary signal can be handled
  • Replace ctrlc with signal-hook to be able to handle specific signals (such as SIGHUP) and be able to propagate them independently, instead of handling them all via a single handler
    • A substantial change was done to handle continuously polling the process via child.try_wait(), instead of handler that was used previously with ctrlc
  • Fix error codes when recipes/commands/shebangs/inline are terminated via a signal by adding 128 to the signal termination code
  • Add command-group to be able to handle shebang command executions which may cause sub-processes to be spawned
  • Re-enable signal/interrupt tests and add a test that validates that multiple signals can be sent if the program is able to trap them

As a side note, I noticed that the current interruption handling mechanism was incrementing the block counter via the block() method, but was never calling unblock() thus decreasing the block counter - I assume this implementation was done with concurrent processes in mind, however it seemed to be incomplete. As far as I am aware there are no concurrent processes/recipes that would need this behaviour, but could definitely take it in mind if required.

Bonus:
Possibly re-fix this other reported issue a while back, which from my shallow understanding, currently multiple Ctrl-C's were not able to be forwarded to the child process due to the aforementioned block counter reason
#302

Please let me know if I should adjust any part of the implementation, more than happy to get some feedback and make appropriate adjustments :)

Copy link
Owner

@casey casey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dope! Lots of comments, mostly because I don't fully understand what's going on here 😅

src/platform.rs Show resolved Hide resolved
src/platform_interface.rs Outdated Show resolved Hide resolved
src/platform.rs Show resolved Hide resolved
src/signal_handler.rs Outdated Show resolved Hide resolved
src/signal_handler.rs Outdated Show resolved Hide resolved
src/signal_handler.rs Outdated Show resolved Hide resolved
src/signal_handler.rs Outdated Show resolved Hide resolved
src/signal_handler.rs Outdated Show resolved Hide resolved
src/signal_handler.rs Outdated Show resolved Hide resolved
src/signal_handler.rs Show resolved Hide resolved
@casey
Copy link
Owner

casey commented Jan 2, 2024

BTW, are you the Davo that I know IRL?

@davoclavo
Copy link
Author

Thanks a lot for the feedback/comments, I will work on fixing them! I will also address the issues clippy surfaced.

And yes, I am that davo from rc 😄 - stoked to see just and ords becoming big creatures!

@davoclavo
Copy link
Author

Alright, comments adjusted, and made some additional improvements I noticed.

I did not mark any of your comments as "resolved" myself, as I am not sure what the right etiquette is for that process, but here is a list of the changes. I think I fixed all or most of your suggestions, and the ones I needed more clarification I left you a response in each thread. Happy to take more feedback if needed.

  • Remove unwrap() calls
  • Implement exit_code_from_signal for windows platform.rs part
  • Refactored use statements
  • Cleaned up commented code
  • Increased sleep time in between polling to 50ms
  • Simplified Signal registering logic
  • Changed SignalHandler::instance method from public to private
  • Deleted SignalHandler::new method
  • Fixed clippy comments, especially the one regarding conversions from u32 to i32

@davoclavo davoclavo force-pushed the improve_signal_handling branch from 3ce9bae to 88cfc22 Compare January 4, 2024 06:14
- Renamed the interrupt_handler to signal_handler to make it more explicit that
any arbitrary signal can be handled
- Replace ctrlc with signal-hook to be able to handle specific signals, and be
able to propagate them transparently
  - A substantial change was done to handle continuously polling the process via
  child.try_wait, instead of handler that was used previously with ctrlc
- Fix error codes when recipes/commands/shebangs/inline are terminated via a
signal
- Add command-group to be able to handle shebang command executions which may
cause sub-processes to be spawned
- Re-enable signal/interrupt tests and add a test that validates that multiple
signals can be sent if the program is able to trap them
- Remove `unwrap()` calls
- Implement `exit_code_from_signal` for windows platform.rs
- Refactored use statements
- Cleaned up commented code
- Increased sleep time in between polling to 50ms
- Simplified Signal registering logic
@davoclavo davoclavo force-pushed the improve_signal_handling branch from 88cfc22 to b293342 Compare January 12, 2024 04:10
@davoclavo
Copy link
Author

Rebased and took the liberty to resolve all trivial comments to make it less of a burden to review

Copy link
Owner

@casey casey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tweaked a few things and pushed them to the branch:

  • Removed SignalHandler::verbosity since it looks like it we don't need it anymore
  • Made SignalHandler::install set the whole struct and inlined some stuff
  • Added #[ignore] back to the test, since for some reason they don't run when I run the tests inside cargo watch
  • Made #[ignore]d tests run on CI
  • Run ignored tests when running just test

It looks like this isn't working on Windows CI, there appear to be some undefined symbols.

@davoclavo
Copy link
Author

davoclavo commented Jan 12, 2024

Removed extended-siginfo feature from signal-hook crate which might be causing this issue, and we didn't really need it in the first place

Could you try running the workflow once again to see if tests pass for the Windows CI workflow?

if it fails, I'll do more research and try to get an easy way to replicate the problem and find a solution 🪟

@casey
Copy link
Owner

casey commented Jan 12, 2024

Just re-ran the checks, it looks like the missing symbol errors are gone, but there are a few more issues.

@davoclavo
Copy link
Author

Pushed a couple more changes to address these new issues, hopefully all the CI checks pass this time 🤞 - thanks for the patience!

Also... I found what seems to be a libc::kill replacement for windows, so we may be able to enable the signal test for windows as well (modulo the test that uses SIGHUP, which apparently is not available in windows). Sadly I don't have a windows box handy to iterate and make sure things work, and have no clue how to set up a windows-latest github runner. I will try to set up one in my fork.

@davoclavo
Copy link
Author

I got my windows runner working and there are some other issues, let me fix them and I will let you know when everything is green

@davoclavo davoclavo force-pushed the improve_signal_handling branch from 2d71beb to dbf9758 Compare January 12, 2024 09:23
@davoclavo davoclavo force-pushed the improve_signal_handling branch from dbf9758 to 3bc9d00 Compare January 12, 2024 09:27
@casey
Copy link
Owner

casey commented May 21, 2024

This looks a little stale, so I'm going to convert it to a draft.

@casey casey marked this pull request as draft May 21, 2024 00:07
@casey
Copy link
Owner

casey commented Nov 19, 2024

This is pretty stale, so closing. See #2473, where I try to get to the bottom, once and for all, of just's current signal handling behavior.

@casey casey closed this Nov 19, 2024
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.

3 participants