[Bug 1567096] Comment bridged from LTC Bugzilla

[Michael Hudson-Doyle]

Hm, that's not what I see, but I am running in a yakkey chroot on a
wily system -- could there be a dependence on kernel version here?

On 3 May 2016 at 05:50, bugproxy <bugproxy at us.ibm.com> wrote:
> ------- Comment From boger at us.ibm.com 2016-05-02 13:45 EDT-------
> Here is a bit more detail on my earlier comment:
>
> You need fsnotify commit 836bfd to see the problem with go1.6.1.  If the
> fsnotify package is built with this commit using go1.6.1 and the test
> built with go1.6.1, then there will be several failures and a hang
> TestInotifyInnerMapLength:
>
> ./fsnotify.test -test.v
> === RUN   TestPollerWithBadFd
> --- PASS: TestPollerWithBadFd (0.00s)
> === RUN   TestPollerWithData
> --- FAIL: TestPollerWithData (0.00s)
> inotify_poller_test.go:85: expected poller to return true
> === RUN   TestPollerWithWakeup
> --- PASS: TestPollerWithWakeup (0.00s)
> === RUN   TestPollerWithClose
> --- FAIL: TestPollerWithClose (0.00s)
> inotify_poller_test.go:119: expected poller to return true
> === RUN   TestPollerWithWakeupAndData
> --- FAIL: TestPollerWithWakeupAndData (0.00s)
> inotify_poller_test.go:140: expected poller to return true
> === RUN   TestPollerConcurrent
> --- FAIL: TestPollerConcurrent (0.05s)
> inotify_poller_test.go:197: expected true
> === RUN   TestInotifyCloseRightAway
> --- PASS: TestInotifyCloseRightAway (0.05s)
> === RUN   TestInotifyCloseSlightlyLater
> --- PASS: TestInotifyCloseSlightlyLater (0.10s)
> === RUN   TestInotifyCloseSlightlyLaterWithWatch
> --- PASS: TestInotifyCloseSlightlyLaterWithWatch (0.10s)
> === RUN   TestInotifyCloseAfterRead
> --- PASS: TestInotifyCloseAfterRead (0.10s)
> === RUN   TestInotifyCloseCreate
> --- FAIL: TestInotifyCloseCreate (0.05s)
> inotify_test.go:136: Took too long to wait for event
> === RUN   TestInotifyStress
> --- FAIL: TestInotifyStress (5.00s)
> inotify_test.go:238: Expected at least 50 creates, got 0
> === RUN   TestInotifyRemoveTwice
> --- PASS: TestInotifyRemoveTwice (0.00s)
> === RUN   TestInotifyInnerMapLength
> <hangs here>
>
> However, if you switch to using go1.6.2, rebuild the fsnotify package and testcase from this same fsnotify commit id and run the test, it passes:
> boger at ampere:~/fsnotify/src/github.com/fsnotify/fsnotify$ go version
> go version go1.6.2 linux/ppc64le
> boger at ampere:~/fsnotify/src/github.com/fsnotify/fsnotify$ go test -c
> boger at ampere:~/fsnotify/src/github.com/fsnotify/fsnotify$ ./fsnotify.test
> PASS
>
> If you change to use the latest commit for fsnotify (containing the
> switch to use x/sys/unix for the header files), rebuild the fsnotify
> package and the test, that seems to work for both go1.6.1 and go1.6.2,
> since it is no longer using the header file from the golang directories
> but from the golang/x directories.
>
> --
> You received this bug notification because you are subscribed to
> golang-1.6 in Ubuntu.
> https://bugs.launchpad.net/bugs/1567096
>
> Title:
>   Docker doesn't work since Containerd integration
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/golang-1.6/+bug/1567096/+subscriptions

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to golang-1.6 in Ubuntu.
https://bugs.launchpad.net/bugs/1567096

Title:
  Docker doesn't work since Containerd integration

Status in golang-1.6 package in Ubuntu:
  Fix Released

Bug description:
  -- Problem Description --
  Docker build hangs indefinitely when run using a 1.11.0 binary built after containerd integration, and go 1.6 on ppc64le. Doing the same thing works with gccgo.

  Looking at the differences in docker logs shows that the containerd
  event "exit", never happens when using a binary built with gc.
  fsnotify, the file system handler for go, doesn't seem to receive the
  correct event when a file is either written to, or closed, which I
  believe is whats causing this issue.

  Link to fsnotify issue which shows some failing tests :
  https://github.com/fsnotify/fsnotify/issues/130

  I have a patch that fixes the errors when I run fsnotify.  I am
  preparing it for submission now and should be out there as a golang CL
  this morning.

  Do you want the patch so you can rebuild golang with it?  If fsnotify
  is a separate package then you will have to rebuild it with the new
  golang.

  Here's the CL link if you want to get the patch for ppc64le:  https://go-review.googlesource.com/#/c/21582/
  Go to the upper right where it says download and I think if you select patch file it will give you the patch.

  We'll update with more info after testing the patch Lynn submitted,
  but we wanted to let Canonical know about this issue in the meantime
  since 1.11 is about to GA upstream.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/golang-1.6/+bug/1567096/+subscriptions