Signed-off-by: John Howard <jhoward@microsoft.com>
| ... | ... |
@@ -11,6 +11,7 @@ import ( |
| 11 | 11 |
"reflect" |
| 12 | 12 |
"runtime" |
| 13 | 13 |
"sort" |
| 14 |
+ "strconv" |
|
| 14 | 15 |
"strings" |
| 15 | 16 |
"sync" |
| 16 | 17 |
"time" |
| ... | ... |
@@ -19,6 +20,7 @@ import ( |
| 19 | 19 |
"github.com/docker/docker/integration-cli/checker" |
| 20 | 20 |
"github.com/docker/docker/integration-cli/cli" |
| 21 | 21 |
"github.com/docker/docker/integration-cli/cli/build" |
| 22 |
+ "github.com/docker/docker/pkg/parsers/kernel" |
|
| 22 | 23 |
"github.com/go-check/check" |
| 23 | 24 |
"gotest.tools/icmd" |
| 24 | 25 |
) |
| ... | ... |
@@ -543,6 +545,38 @@ func (s *DockerSuite) TestExecEnvLinksHost(c *check.C) {
|
| 543 | 543 |
|
| 544 | 544 |
func (s *DockerSuite) TestExecWindowsOpenHandles(c *check.C) {
|
| 545 | 545 |
testRequires(c, DaemonIsWindows) |
| 546 |
+ |
|
| 547 |
+ if runtime.GOOS == "windows" {
|
|
| 548 |
+ v, err := kernel.GetKernelVersion() |
|
| 549 |
+ c.Assert(err, checker.IsNil) |
|
| 550 |
+ build, _ := strconv.Atoi(strings.Split(strings.SplitN(v.String(), " ", 3)[2][1:], ".")[0]) |
|
| 551 |
+ if build >= 17743 {
|
|
| 552 |
+ c.Skip("Temporarily disabled on RS5 17743+ builds due to platform bug")
|
|
| 553 |
+ |
|
| 554 |
+ // This is being tracked internally. @jhowardmsft. Summary of failure |
|
| 555 |
+ // from an email in early July 2018 below: |
|
| 556 |
+ // |
|
| 557 |
+ // Platform regression. In cmd.exe by the look of it. I can repro |
|
| 558 |
+ // it outside of CI. It fails the same on 17681, 17676 and even as |
|
| 559 |
+ // far back as 17663, over a month old. From investigating, I can see |
|
| 560 |
+ // what's happening in the container, but not the reason. The test |
|
| 561 |
+ // starts a long-running container based on the Windows busybox image. |
|
| 562 |
+ // It then adds another process (docker exec) to that container to |
|
| 563 |
+ // sleep. It loops waiting for two instances of busybox.exe running, |
|
| 564 |
+ // and cmd.exe to quit. What's actually happening is that the second |
|
| 565 |
+ // exec hangs indefinitely, and from docker top, I can see |
|
| 566 |
+ // "OpenWith.exe" running. |
|
| 567 |
+ |
|
| 568 |
+ //Manual repro would be |
|
| 569 |
+ //# Start the first long-running container |
|
| 570 |
+ //docker run --rm -d --name test busybox sleep 300 |
|
| 571 |
+ |
|
| 572 |
+ //# In another window, docker top test. There should be a single instance of busybox.exe running |
|
| 573 |
+ //# In a third window, docker exec test cmd /c start sleep 10 NOTE THIS HANGS UNTIL 5 MIN TIMEOUT |
|
| 574 |
+ //# In the second window, run docker top test. Note that OpenWith.exe is running, one cmd.exe and only one busybox. I would expect no "OpenWith" and two busybox.exe's. |
|
| 575 |
+ } |
|
| 576 |
+ } |
|
| 577 |
+ |
|
| 546 | 578 |
runSleepingContainer(c, "-d", "--name", "test") |
| 547 | 579 |
exec := make(chan bool) |
| 548 | 580 |
go func() {
|