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
Implement process_vm_readv and process_vm_writev for the same user only #158
Comments
Hi, Just in case you need a real-world example, I have been troubleshooting this for the last couple of days: I built a Nginx + PHP-FPM container to run Laravel apps on Google Cloud Run. We saw that some requests took very long to complete. Upon inspection, those requests returned a bigger payload then others and were chunked as separate tasks. The first part would complete almost instantly and then wait up until the PHP-FPM slowlog timeout. After that the second part of the response was delivered. If we set the timeout to 10s, it would takes that long for the page to load. I ran the container locally and put the code on a cloud VM. Neither one showed the same symptoms. I then strace'd the syscalls in gvisor and Cloud Run output this message:
I believe that the PHP-FPM processes use this syscall to communicate with each other or the PHP-FPM master process. For the time being, we use strace as a MITM for all the syscalls coming from PHP-FPM in order to catch the unsupported one and report it instead of waiting for it to timeout. |
This message only appeared when running strace, if I understand correctly? strace itself actually uses |
Yes, that's right. Only when running strace I see the error in the Cloud Run logging. Thanks for clarifying. It's the only syscall I see that is unsupported according to the logs, so I'll look elsewhere. Still odd that putting strace in between resolves the issue. |
I missed that part, it is odd indeed. To me that seems to suggest some sort of race condition for which strace is slowing things down enough to usually come out on the lucky side of. |
.Net debugger requires |
Hi @fvoznika, I actually found that this was an error in their implementation (at least for |
This feature has been implemented in PR7844. Let me know if there are issues. |
(We can disregard the cases were cap_sys_ptrace is required)
The text was updated successfully, but these errors were encountered: