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

os: write should handle EINTR [1.14 backport] #39026

Closed
gopherbot opened this issue May 12, 2020 · 3 comments
Closed

os: write should handle EINTR [1.14 backport] #39026

gopherbot opened this issue May 12, 2020 · 3 comments

Comments

@gopherbot
Copy link

@gopherbot gopherbot commented May 12, 2020

@networkimprov requested issue #38033 to be considered for backport to the next 1.14 minor release.

@gopherbot please backport to 1.14, which introduced this issue.

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented May 12, 2020

Sorry, we aren't going to backport the EINTR change to 1.14. That is much too invasive and risky.

1.14 did not introduce this problem, it merely made it occur more often. The workaround of setting GODEBUG will reduce the number of times the problems occurs back to 1.13 levels.

@dsoprea
Copy link

@dsoprea dsoprea commented May 12, 2020

@dsoprea
Copy link

@dsoprea dsoprea commented May 12, 2020

adunham-stripe added a commit to adunham-stripe/cgroups that referenced this issue Jul 7, 2020
Go 1.14 introduces asynchronous preemption, which results in
applications that invoke slow syscalls (e.g. writing to a cgroup file)
getting EINTR errors. The Go runtime will fix this in version 1.15
onwards:
    golang/go#38033

But this fix won't be backported:
    golang/go#39026 (comment)

As such, introduce a 'writeFile' helper function that retries when the
error is an EINTR error.
adunham-stripe added a commit to adunham-stripe/cgroups that referenced this issue Jul 7, 2020
Go 1.14 introduces asynchronous preemption, which results in
applications that invoke slow syscalls (e.g. writing to a cgroup file)
getting EINTR errors. The Go runtime will fix this in version 1.15
onwards:
    golang/go#38033

But this fix won't be backported:
    golang/go#39026 (comment)

As such, introduce a 'writeFile' helper function that retries when the
error is an EINTR error.

Signed-off-by: Andrew Dunham <adunham@stripe.com>
adunham-stripe added a commit to adunham-stripe/cgroups that referenced this issue Jul 7, 2020
Go 1.14 introduces asynchronous preemption, which results in
applications that invoke slow syscalls (e.g. writing to a cgroup file)
getting EINTR errors. The Go runtime will fix this in version 1.15
onwards:
    golang/go#38033

But this fix won't be backported:
    golang/go#39026 (comment)

As such, introduce a 'writeFile' helper function that retries when the
error is an EINTR error.

Signed-off-by: Andrew Dunham <adunham@stripe.com>
adunham-stripe added a commit to adunham-stripe/cgroups that referenced this issue Jul 7, 2020
Go 1.14 introduces asynchronous preemption, which results in
applications that invoke slow syscalls (e.g. writing to a cgroup file)
getting EINTR errors. The Go runtime will fix this in version 1.15
onwards:
    golang/go#38033

But this fix won't be backported:
    golang/go#39026 (comment)

As such, introduce a 'writeFile' helper function that retries when the
error is an EINTR error.

Signed-off-by: Andrew Dunham <adunham@stripe.com>
copybara-service bot pushed a commit to google/gvisor that referenced this issue Jul 8, 2020
After deploying a version of gvisor built with Go 1.14, we're seeing errors setting up cgroups (we manually run `runsc` via `runsc run`, which creates the cgroup). This turns out to be a known issue with Go: golang/go#38033. Given that the [fix won't be backported](golang/go#39026 (comment)), we should retry writes that may fail with EINTR.

This is also what runc does: opencontainers/runc#2258

FUTURE_COPYBARA_INTEGRATE_REVIEW=#3102 from stripe:andrew/cgroup-eintr 079123b
PiperOrigin-RevId: 320183771
copybara-service bot pushed a commit to google/gvisor that referenced this issue Jul 8, 2020
After deploying a version of gvisor built with Go 1.14, we're seeing errors setting up cgroups (we manually run `runsc` via `runsc run`, which creates the cgroup). This turns out to be a known issue with Go: golang/go#38033. Given that the [fix won't be backported](golang/go#39026 (comment)), we should retry writes that may fail with EINTR.

This is also what runc does: opencontainers/runc#2258

FUTURE_COPYBARA_INTEGRATE_REVIEW=#3102 from stripe:andrew/cgroup-eintr 079123b
PiperOrigin-RevId: 320183771
copybara-service bot pushed a commit to google/gvisor that referenced this issue Jul 8, 2020
After deploying a version of gvisor built with Go 1.14, we're seeing errors setting up cgroups (we manually run `runsc` via `runsc run`, which creates the cgroup). This turns out to be a known issue with Go: golang/go#38033. Given that the [fix won't be backported](golang/go#39026 (comment)), we should retry writes that may fail with EINTR.

This is also what runc does: opencontainers/runc#2258

FUTURE_COPYBARA_INTEGRATE_REVIEW=#3102 from stripe:andrew/cgroup-eintr 079123b
PiperOrigin-RevId: 320183771
copybara-service bot pushed a commit to google/gvisor that referenced this issue Jul 8, 2020
After deploying a version of gvisor built with Go 1.14, we're seeing errors setting up cgroups (we manually run `runsc` via `runsc run`, which creates the cgroup). This turns out to be a known issue with Go: golang/go#38033. Given that the [fix won't be backported](golang/go#39026 (comment)), we should retry writes that may fail with EINTR.

This is also what runc does: opencontainers/runc#2258

FUTURE_COPYBARA_INTEGRATE_REVIEW=#3102 from stripe:andrew/cgroup-eintr 079123b
PiperOrigin-RevId: 320183771
copybara-service bot pushed a commit to google/gvisor that referenced this issue Jul 8, 2020
After deploying a version of gvisor built with Go 1.14, we're seeing errors setting up cgroups (we manually run `runsc` via `runsc run`, which creates the cgroup). This turns out to be a known issue with Go: golang/go#38033. Given that the [fix won't be backported](golang/go#39026 (comment)), we should retry writes that may fail with EINTR.

This is also what runc does: opencontainers/runc#2258

FUTURE_COPYBARA_INTEGRATE_REVIEW=#3102 from stripe:andrew/cgroup-eintr 079123b
PiperOrigin-RevId: 320183771
copybara-service bot pushed a commit to google/gvisor that referenced this issue Jul 28, 2020
After deploying a version of gvisor built with Go 1.14, we're seeing errors setting up cgroups (we manually run `runsc` via `runsc run`, which creates the cgroup). This turns out to be a known issue with Go: golang/go#38033. Given that the [fix won't be backported](golang/go#39026 (comment)), we should retry writes that may fail with EINTR.

This is also what runc does: opencontainers/runc#2258

FUTURE_COPYBARA_INTEGRATE_REVIEW=#3102 from stripe:andrew/cgroup-eintr 079123b
PiperOrigin-RevId: 323575152
copybara-service bot pushed a commit to google/gvisor that referenced this issue Jul 28, 2020
After deploying a version of gvisor built with Go 1.14, we're seeing errors setting up cgroups (we manually run `runsc` via `runsc run`, which creates the cgroup). This turns out to be a known issue with Go: golang/go#38033. Given that the [fix won't be backported](golang/go#39026 (comment)), we should retry writes that may fail with EINTR.

This is also what runc does: opencontainers/runc#2258

FUTURE_COPYBARA_INTEGRATE_REVIEW=#3102 from stripe:andrew/cgroup-eintr 079123b
PiperOrigin-RevId: 323575152
copybara-service bot pushed a commit to google/gvisor that referenced this issue Jul 28, 2020
After deploying a version of gvisor built with Go 1.14, we're seeing errors setting up cgroups (we manually run `runsc` via `runsc run`, which creates the cgroup). This turns out to be a known issue with Go: golang/go#38033. Given that the [fix won't be backported](golang/go#39026 (comment)), we should retry writes that may fail with EINTR.

This is also what runc does: opencontainers/runc#2258

FUTURE_COPYBARA_INTEGRATE_REVIEW=#3102 from stripe:andrew/cgroup-eintr 079123b
PiperOrigin-RevId: 323575152
copybara-service bot pushed a commit to google/gvisor that referenced this issue Jul 28, 2020
After deploying a version of gvisor built with Go 1.14, we're seeing errors setting up cgroups (we manually run `runsc` via `runsc run`, which creates the cgroup). This turns out to be a known issue with Go: golang/go#38033. Given that the [fix won't be backported](golang/go#39026 (comment)), we should retry writes that may fail with EINTR.

This is also what runc does: opencontainers/runc#2258

FUTURE_COPYBARA_INTEGRATE_REVIEW=#3102 from stripe:andrew/cgroup-eintr 079123b
PiperOrigin-RevId: 323575152
copybara-service bot pushed a commit to google/gvisor that referenced this issue Jul 28, 2020
After deploying a version of gvisor built with Go 1.14, we're seeing errors setting up cgroups (we manually run `runsc` via `runsc run`, which creates the cgroup). This turns out to be a known issue with Go: golang/go#38033. Given that the [fix won't be backported](golang/go#39026 (comment)), we should retry writes that may fail with EINTR.

This is also what runc does: opencontainers/runc#2258

FUTURE_COPYBARA_INTEGRATE_REVIEW=#3102 from stripe:andrew/cgroup-eintr 079123b
PiperOrigin-RevId: 323575152
copybara-service bot pushed a commit to google/gvisor that referenced this issue Jul 28, 2020
After deploying a version of gvisor built with Go 1.14, we're seeing errors setting up cgroups (we manually run `runsc` via `runsc run`, which creates the cgroup). This turns out to be a known issue with Go: golang/go#38033. Given that the [fix won't be backported](golang/go#39026 (comment)), we should retry writes that may fail with EINTR.

This is also what runc does: opencontainers/runc#2258

FUTURE_COPYBARA_INTEGRATE_REVIEW=#3102 from stripe:andrew/cgroup-eintr 079123b
PiperOrigin-RevId: 323575152
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.