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

Do not support SIGUSR1 and SIGUSR2 syscall handling in windows #970

Merged
merged 6 commits into from
Sep 23, 2016

Conversation

cyli
Copy link
Contributor

@cyli cyli commented Sep 22, 2016

Since they don't exist in Windows. While I was at it, since I had to create a bunch of windows-specific and non-windows-specific files, I moved the signal handling code to utils so that it can also be used by the signer (that way we don't have windows/non-windows files for both server and signer).

Technically I think the only change that would have been necessary to make the windows client build is the const.go change, and I don't think we care about supporting windows for server/signer, but the server and signer changes are added for completeness (and if we want to run full unit tests in windows).

Unfortunately we don't have any windows CI systems yet. :| Although I did add at least cross-compiling to windows to our CI runs.

Addresses part of #551.
Fixes #791.

Note: possibly we want to rebase this to 0.4.0 so that it can be added to 0.4.1

@HuKeping
Copy link
Contributor

Haven't tried notary on Windows, but changes LGTM

@cyli cyli force-pushed the windows-syscall branch 4 times, most recently from 41beaf8 to 393783c Compare September 22, 2016 07:21
@cyli cyli changed the title WIP: Do not support SIGUSR1 and SIGUSR2 syscall handling in windows Do not support SIGUSR1 and SIGUSR2 syscall handling in windows Sep 22, 2016
@cyli cyli modified the milestone: Notary 0.4.1 Sep 22, 2016
Copy link
Contributor

@riyazdf riyazdf left a comment

Choose a reason for hiding this comment

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

Thank you for fixing this! LGTM but would be great to kick the tires on this PR on a windows box before merge (cc @endophage)

@@ -210,6 +210,42 @@ The environment variables for the older passwords are optional, but Notary
Signer will not be able to decrypt older keys if they are not provided, and
attempts to sign data using those keys will fail.

## Hot logging level reload
We don't support completely reloading notary signer configuration files yet at present. What we support for now is:
Copy link
Contributor

Choose a reason for hiding this comment

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

It might be worth making a note about how this is not supported in Windows

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Great idea, done. :)


// SetupSignalTrap is a utility to trap supported signals hand handle them (currently by increasing logging)
func SetupSignalTrap(handler func(os.Signal)) chan os.Signal {
if len(notary.NotarySupportedSignals) == 0 {
Copy link
Contributor

@riyazdf riyazdf Sep 22, 2016

Choose a reason for hiding this comment

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

non-blocking-nit: can we test this case with some mocking? I'm fine with assigning this const to empty for the test and deferring to return it back to its original value, to mock what Windows would do

Copy link
Contributor Author

Choose a reason for hiding this comment

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

👍 I was actually going to see if I could try to set up CI for windows (not sure if we want to do it in this PR) so that we can get coverage numbers for it, in which case this should be tested. I'll follow up on this later today and if it proves to be a ton of work I'll stub out the const instead. :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ok, I think we can probably set this up. In case it goes horribly badly and doesn't work, I've added a mocking test for this in a commit we can revert once we have the CI set up.

@@ -0,0 +1,8 @@
// +build windows
Copy link
Contributor

Choose a reason for hiding this comment

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

Fine with leaving it in for explicit-ness but for my own understanding, we don't technically need it when using the *_windows.go filename right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yep, not needed. I just like having the labels since we also have a nowindows that matches against everything else.

return
}
case syscall.SIGUSR2:
if err := AdjustLogLevel(false); err != nil {
Copy link
Contributor

Choose a reason for hiding this comment

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

Curious why the error case for SIGUSR1 is being covered but this one isn't. Can't work out why that would be that case.

Copy link
Contributor

@riyazdf riyazdf Sep 22, 2016

Choose a reason for hiding this comment

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

I think it's this line, when it testsDebug + SIGUSR1 -> Debug: https://github.com/docker/notary/pull/970/files#diff-d39909358e7e39607c560d5d0fad0823R26

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hopefully I've fixed this so we test the same set of log level adjustments for both AdjustLogLevel and the signal handler. We'll see what coverage says.

Signed-off-by: Ying Li <ying.li@docker.com>
Copy link
Contributor

@endophage endophage left a comment

Choose a reason for hiding this comment

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

LGTM on @cyli's changes. Somebody should probably LGTM again for my one-liner.

@endophage
Copy link
Contributor

Can run the client tests and build+run notary client on windows 👍

@riyazdf
Copy link
Contributor

riyazdf commented Sep 22, 2016

LGTM on @endophage's commit, so overall LGTM from me 👍

Merge on green after rebase for hotfix/0.4.1!

cyli and others added 3 commits September 22, 2016 14:45
…both for using with handles and with AdjustLogLevel

Signed-off-by: Ying Li <ying.li@docker.com>
Add cross-compiling for supported platforms to our CircleCI builders.

Signed-off-by: Ying Li <ying.li@docker.com>
…igOrAbsolute

Signed-off-by: David Lawrence <david.lawrence@docker.com> (github: endophage)
@cyli cyli changed the base branch from master to hotfix/0.4.1 September 22, 2016 21:54
old := notary.NotarySupportedSignals
notary.NotarySupportedSignals = nil
defer func() {
notary.NotarySupportedSignals = old
Copy link
Contributor

Choose a reason for hiding this comment

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

I think not deferring this and moving it to after testSetSignalTrap will solve the race checker problem.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Cool, thanks!

@cyli
Copy link
Contributor Author

cyli commented Sep 23, 2016

If I rebase to master, the race condition goes away... strange.

Update: Oh, it's because of the code coverage calculation script changes - since I'm not building against every single package anymore. Just using that files makes the race condition go away. I'm not sure that's a good thing. I wonder if there's any conflict with some other package...

@cyli
Copy link
Contributor Author

cyli commented Sep 23, 2016

Oh, no. It's because covermode is still count on this branch, as opposed to atomic, which does more precise counting when there's parallelism.

…here no signals are supported.

Revert this commit when we have actual CI tests running under windows.

Signed-off-by: Ying Li <ying.li@docker.com>
Signed-off-by: Ying Li <ying.li@docker.com>
@riyazdf
Copy link
Contributor

riyazdf commented Sep 23, 2016

newest changes LGTM

@cyli cyli merged commit 85f320e into hotfix/0.4.1 Sep 23, 2016
@cyli cyli deleted the windows-syscall branch September 23, 2016 17:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants