"Unsupported syscall" on Cloud Run

tjdam

Hi!

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?

Thanks!

8 comments

#deployment #google-cloud-provider

1 3561 8

2022-01-09 07:41:56 UTC

Showing Posts 1 to 8

Show Best Posts
Show All (oldest first)
Show All (newest first)

derek-zhou

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.

Post #1

tjdam

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?

Post #2

kip

ex_cldr Core Team

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 …

Post #3

tjdam

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

Post #4

jtormey

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

Post #5

tjdam

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

Post #7

batbabydev

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! ) …

Documentation about this can be found Cloud Run Execution Environments

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

Post #8