Unsupported syscall sys_1008 + killed

[Travis DePrato]

I'm noticing a few pods have this issue:

Unsupported syscall sys_1008(0x0,0x0,0x0,0x0,0x0,0x0). It is likely that you can safely ignore this message and that this is not the cause of any error. Please, refer to https://gvisor.dev/c/linux/amd64/sys_1008 for more information.

That link goes to a 404 page, and, infact, Googling "sys_1008" yields practically zero results.

gVisor then immediately logs:

Uncaught signal: \"killed\" (9), PID: 15, TID: 18, fault addr: 0x0

multiple times before the pod is ultimately deleted.

I can't reproduce this when I try to, so I'm curious if anyone has any insights.

For context, I'm running on GKE.

[Adin Scannell]

There is no syscall 1008, so it seems like this is an application going off the rails a bit (e.g. an application crash). It's hard to say why it is being killed subsequently, but it could be the result of a pointer exception or something else. This could be the "normal" application behavior (e.g. the same as native execution) or it could be some code path that the application has steered into because something else in the gVisor execution environment is different.

Are there any details of the container image that you could share? E.g. is it a standard runtime/framework or anything?

--
You received this message because you are subscribed to the Google Groups "gVisor Users [Public]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gvisor-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gvisor-users/cd5a67c9-df18-44fa-8335-cfb235b9d2a8n%40googlegroups.com.

[Travis DePrato]

Thanks for the reply! I think the syscall 1008 bit might have been a red herring - it doesn't seem to be an issue any more. Will update if I notice anything. For context, using Julia + ZMQ (my best guess for why a nonexistent syscall would be invoked would be something going wrong with Julia's CZMQ FFI stuff but unsure).