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

add a global signal handler for interrupts #1118

Merged
merged 9 commits into from Nov 16, 2020

Conversation

mdrohmann
Copy link
Collaborator

@mdrohmann mdrohmann commented Nov 13, 2020

@mdrohmann
Copy link
Collaborator Author

@Naatan This is how I think it can be done. As mentioned earlier it is not pretty, as it relies on some globally created channels right now.

There is still an open question on how to implement the activate, user-interrupt-error event (AC 4) though: https://www.pivotaltracker.com/story/show/175721061/comments/219706870

@@ -177,33 +175,13 @@ func binaryPathCmd(env []string, name string) (string, error) {
return split[0], nil
}

func ignoreInterrupts(ctx context.Context) {
Copy link
Member

Choose a reason for hiding this comment

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

I don't think we should be removing this. IIRC it is required so as not to bubble stuff up from the subshell context. For this story we're concerned with interrupts happening outside of subshell.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yes, this is now replaced by this sighandler.IgnoreInterrupts() function, as we are now listening for interrupts on the captain.Command-level.

var ignoreCh chan bool

// Init initializes the global signal interrupt handler
func Init(subCommand string) {
Copy link
Member

Choose a reason for hiding this comment

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

Can we use New and return a struct that can be closed. We don't want to still be capturing this after the captain runner has finished.

Comment on lines 29 to 32
logging.Debug("captured ctrl-c event")
analytics.EventWithLabel(analytics.CatCommandExit, subCommand, "interrupt")
analytics.WaitForAllEvents(time.Second)
os.Exit(1)
Copy link
Member

Choose a reason for hiding this comment

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

Why are you calling os.Exit? Big red flag. We want to bubble up interrupts as errors.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I did it this way, because that is the default behavior of ctrl-c. It exits the programme with a non-zero exit code. Here we just inject our analytics code before.

I could add another channel, and run the c.execute() function in a go function, such that I could listen for what returns first: the main path (c.execute or the signal handler). That should be a little nicer.

Comment on lines 29 to 32
logging.Debug("captured ctrl-c event")
analytics.EventWithLabel(analytics.CatCommandExit, subCommand, "interrupt")
analytics.WaitForAllEvents(time.Second)
os.Exit(1)
Copy link
Member

Choose a reason for hiding this comment

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

Can we handle this outside this package.

Something like:

sh := sighandler.New()
defer sh.Close()
sh.OnInterrupt(func () { ... })

@mdrohmann mdrohmann requested review from daved and removed request for Naatan November 16, 2020 17:52
- rename Stop() -> Pause()
- add WaitGroup
- add mutex
@swagile1 swagile1 merged commit 6790bab into master Nov 16, 2020
@mdrohmann mdrohmann deleted the martind/ctrl-c-captured-175721061 branch November 17, 2020 00:15
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.

None yet

4 participants