-
Notifications
You must be signed in to change notification settings - Fork 18k
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
runtime: allow reading sysfs, etc with ignoring event scanning error #30817
Comments
We've seen this popping up in LXD's automated testing starting over the past two days or so, suggesting a pretty recent regression. |
Thanks for the report. In general, using your own polling stuff is better to read sysfs-like virtual files because the runtime-integrated network poller never uses EPOLLPRI or a pair of EPOLLPRI+EPOLLERR which is able to provide the special sign, for example, actual data reception from the underlying device. For backward compatibility, I'll make the poller a bit conservative to allow most user-configured files to ignore event scanning errors except the case of /dev/net/tun-like misconfigured stuff blocking the subsequent I/O calls forever. @ianlancetaylor, any opinion? |
I don't know enough to have an opinion. Why would the poller sometimes return |
For example, on some special files, EPOLLIN+EPOLLOUT indicates the underlying stuff is ready for operation and EPOLLPRI+EPOLLERR indicates actual data reception. Other stuff uses another combination. Fortunately, we may use an individual POLLERR, EPOLLERR or EV_ERROR as a critical state by convention the same as marking all events as the end of a session; see https://go-review.googlesource.com/c/go/+/167777 |
Change https://golang.org/cl/167777 mentions this issue: |
I hit this while trying to use https://github.com/aclements/perflock on a recent Go build. I was scratching my head for a good fifteen minutes until I realised it wasn't setting the right CPU frequency because of these read errors. |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
No, this is only reproducible with master, 1.10, 1.11 and 1.12 are all unaffected.
What operating system and processor architecture are you using (
go env
)?Linux buildd01 4.15.0-46-generic #49-Ubuntu SMP Wed Feb 6 09:33:07 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
go env
OutputWhat did you do?
Attempted multiple parallel reads of the same file from /sys
What did you expect to see?
No errors, all reads succeeding as they do with all other tested Go versions
What did you see instead?
Tests so far show about a 15% failure rate on that ReadFile call.
The text was updated successfully, but these errors were encountered: