[Django]-Bad request (400) (unsupported syscall) when trying to reach container in Google Cloud Run

There is a high chance that the “unsupported syscall” log is actually not causing any problems to your application. These logs are mostly a warning, and most of the time applications fallback to other syscalls or options to get the job done.

(Many Cloud Run users see this warning in their logs, but most of the time their error is stemming from another issue –however this warning picks their attention so they tend to assume it’s the root cause.)

Can you please try running your application locally on Docker using these instructions https://cloud.google.com/run/docs/testing/local and verify if your applications boots fine locally? (Please let me know in the comments).

In this case, the 0x9 option to setsockopt suggests SO_DEBUG and SO_KEEPALIVE. I’m guessing SO_DEBUG might not have been implemented. So if you’re running your WSGI server in debug mode, maybe try disabling that in your prod container?

Update(Dec 9, 2019): setsockopt(0x4,0x6,0x9,..) signature suggests 0x6=SOL_TCP, 0x9=TCP_DEFER_ACCEPT. In this case, our internal investigation revealed that gVisor does not yet support TCP_DEFER_ACCEPT option, which is set by uWSGI. So we’ve started to work on addressing this in gVisor. In the meanwhile, this application most likely won’t work on Cloud Run. Hope you try again later.

In the troubleshooting documentation for Cloud Run, we see a section called “Is your issue caused by a limitation in the container sandbox?” (See here). Following the links we find that the container runs in a special sandbox and then we see that there are OS constraints (limitations). Following this to here we then find this line for the setsockopt() system call:

54  setsockopt  Partial Support Not all socket options are supported.

and I think this is the punch line. The code running in the container is making a setsockopt() OS system call passing in parameters that are explicitly not supported/permitted in the gVisor runtime. The only solution I can think of is to work back through the logic of the code that is running the container and see if we can find where that call is being made and why. There might be options we can supply to cause that path to be avoided.

Sorry, this is not a complete answer but I don’t have enough “reputations” to leave a comment!!

The exact same issue happened to me after changing my DOCKERFILE to pull the image google/cloud-sdk:latest. I haven’t figured out a good workaround for this but my application works perfectly fine, except the fact that my logs get spammed by this warning. I am pointing this out since I believe one of the applications installed in this docker image is causing it.