Skip to content

removing unnecessary exit from plugin processes#1848

Merged
balopat merged 2 commits intoGoogleContainerTools:masterfrom
balopat:remove_unnecessary_exit_from_plugin
Mar 21, 2019
Merged

removing unnecessary exit from plugin processes#1848
balopat merged 2 commits intoGoogleContainerTools:masterfrom
balopat:remove_unnecessary_exit_from_plugin

Conversation

@balopat
Copy link
Copy Markdown
Contributor

@balopat balopat commented Mar 21, 2019

We thought that the default warning message means something is wrong when we saw it by default from hashicorps go-plugin after a Ctrl+C signal is received:

{"@level":"debug","@message":"plugin received interrupt signal, ignoring","@timestamp":"2019-03-20T16:40:56.592099-07:00","count":1}
2019-03-20T16:40:56.593-0700 [DEBUG] plugin.skaffold: plugin received interrupt signal, ignoring: count=1 timestamp=2019-03-20T16:40:56.592-0700

It turns out it behaves exactly what it needs to: it swallows the signal and ignores it - leaving the chance for the main process to cleanup.

The plugins.CleanupPlugins() call should be called from the main process which is now implemented there.

The logging level for plugins can be configured via the DefaultPluginLogLevel that is now set to Info instead of Debug. A follow-up PR could be to get this from an environment variable that the main process sets for the plugin to set the same level of debugging as the main process.

@codecov-io
Copy link
Copy Markdown

Codecov Report

Merging #1848 into master will increase coverage by 0.04%.
The diff coverage is 15.9%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #1848      +/-   ##
==========================================
+ Coverage   49.18%   49.22%   +0.04%     
==========================================
  Files         166      166              
  Lines        7287     7287              
==========================================
+ Hits         3584     3587       +3     
+ Misses       3357     3351       -6     
- Partials      346      349       +3
Impacted Files Coverage Δ
cmd/skaffold/app/cmd/run.go 34.61% <0%> (-1.39%) ⬇️
cmd/skaffold/app/cmd/dev.go 13.27% <0%> (-0.37%) ⬇️
cmd/skaffold/app/cmd/build.go 23.8% <0%> (-0.59%) ⬇️
pkg/skaffold/build/plugin/core.go 33.33% <28.57%> (+21.33%) ⬆️
cmd/skaffold/app/skaffold.go 50% <42.85%> (-10%) ⬇️
pkg/skaffold/plugin/builders/docker/docker.go 8.33% <8.33%> (+8.33%) ⬆️
pkg/skaffold/plugin/builders/bazel/bazel.go 8.33% <8.33%> (+8.33%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7152e30...806813d. Read the comment docs.

err := <-errCh

if err == cancelError {
hashiplugin.CleanupClients()
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

this is the key removal - on Ctrl+C the plugin was self-destructing.

Copy link
Copy Markdown
Contributor

@nkubala nkubala left a comment

Choose a reason for hiding this comment

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

great find, thanks for digging into this!

as we discussed offline, if the skaffold main process dies unexpectedly, the plugin RPC server processes will be abandoned. doesn't need to come in this PR, but we should at least open an issue to implement either

  • a mechanism to tie the child processes to the parent processes so when the parent dies the children go with it, or
  • a heartbeat coming from the plugin server to the skaffold main, so when it realizes the main process is dead it can kill itself.

Copy link
Copy Markdown
Contributor

@priyawadhwa priyawadhwa left a comment

Choose a reason for hiding this comment

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

thanks for fixing this! had one question

}
if err != nil {
if errors.Cause(err) != runner.ErrorConfigurationChanged {
plugin.CleanupClients()
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

just a question -- why did you opt to have these twice and remove the defer function?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

because you're not suppose to call defer in a for loop this way - it might actually end up causing problems across dev cycles. one nice explanation is here: https://blog.learngoprogramming.com/gotchas-of-defer-in-go-1-8d070894cb01 - I could have switched over to an anonymous function as well...

@balopat balopat merged commit 3d7f41e into GoogleContainerTools:master Mar 21, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants