"Unsupported syscall" on Cloud Run


I’ve been using GCP’s Cloud Run on my first Elixir project, and except for this (up to this point) little inconvenience, it’s been a smooth sail.

For most of requests hitting the server, the following message is logged 8 times right after (each with a different set of hex numbers):
Container Sandbox: Unsupported syscall getsockopt(0x1d,0x1,0xc,0x3ebce75fc6a8,0x3ebce75fc6ac,0x3ebce8980170). 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/getsockopt for more information.

I tried to Google this warning and all I could find was other people with similar issues but no actual solution. Some of them reported seeing this when using RabbitMQ which I believe is written in Erlang, so I was wondering if it’s related to OTP in any way.

I tried to read more about it, but I don’t even know where to start.
One thing I did try was to change the Linux distro I was using from Alpine to Debian, but nothing really changed.

Anyone here using Cloud Run had this issue at all?


1 Like

The third argument to getsockopt(2) is 0xc which is SO_PRIORITY See [socket(7) - Linux manual page] for details. So gvisor does not support this socket option.


Hi, thanks for your input!

The thing is, at this point in my journey my understanding of my own application is so high level that I don’t even know what it triggers that and where to look at. I’m assuming it would be something triggered by either Phoenix or some dependency I brought in? Or even, could it be related to the way I built my Docker image?

Perhaps the ranch socket acceptor (which is underneath cowboy which is underneath Phoenix) is setting this option? And perhaps 8 messages because you have one socket acceptor per scheduler (default maybe being one scheduler per core)?

Looks like the maybe relevant function in ranch sets socket options but I think these can also be overridden in configuration.

The option type does reference the option :priority.

Not a solution to your issue but perhaps a few pointers …


Thank you for the insight!

It gives me some idea on where to start investigating. I’ve been reading about sockets today, something I didn’t know much about at all :slight_smile:

Did you have any luck with that priority option? I’m able to filter out these logs in GCP, but it is definitely a pain to do. I’d rather my application simply not generate them :slightly_smiling_face:

No, not really… :confused:
I learned to live with it, but probably shouldn’t :sweat_smile:

Hope this helps someone …

For GCP and Cloud Run the solution is to consider the execution environments when deploying. There are trade offs between gen1 and gen2 environments. I have found gen2 to work well (and the logs disappear! :slight_smile: ) …

Documentation about this can be found Cloud Run Execution Environments

ps - thanks for the ranch info!! … was really useful!! …


Oh my god, thank you so much!!!

I can’t believe I can finally read my logs clearly hahah :sob: