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

Implement process_vm_readv and process_vm_writev for the same user only #158

Open
amscanne opened this issue Mar 25, 2019 · 4 comments
Open

Implement process_vm_readv and process_vm_writev for the same user only #158

amscanne opened this issue Mar 25, 2019 · 4 comments

Comments

@amscanne
Copy link
Collaborator

@amscanne amscanne commented Mar 25, 2019

(We can disregard the cases were cap_sys_ptrace is required)

@alexdesmet
Copy link

@alexdesmet alexdesmet commented Dec 10, 2020

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:

Container Sandbox: Unsupported syscall process_vm_readv(0xf,0x3ede59f9c830,0x1,0x3ede59f9c840,0x1,0x0). It is very likely that you can safely ignore this message and that this is not the cause of any error you might be troubleshooting. Please, refer to https://gvisor.dev/c/linux/amd64/process_vm_readv for more information.

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.

@prattmic
Copy link
Member

@prattmic prattmic commented Dec 10, 2020

I then strace'd the syscalls in gvisor and Cloud Run output this message:

This message only appeared when running strace, if I understand correctly? strace itself actually uses process_vm_readv (with a fallback to PTRACE_PEEKDATA when it's not supported in gVisor), so this is expected and unrelated to your application.

@alexdesmet
Copy link

@alexdesmet alexdesmet commented Dec 10, 2020

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.

@prattmic
Copy link
Member

@prattmic prattmic commented Dec 10, 2020

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.

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