From b09873110ae2dd24e2a033737174008d6bdc51db Mon Sep 17 00:00:00 2001 From: Paul Fitzpatrick Date: Tue, 16 Apr 2024 15:18:57 -0400 Subject: [PATCH] list some reasons why gvisor sandboxing may fail (#330) This follows a suggestion given in https://github.com/gristlabs/grist-core/issues/914#issuecomment-2022610020 --- help/en/docs/self-managed.md | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/help/en/docs/self-managed.md b/help/en/docs/self-managed.md index d2cf352f8..cc34c0cb1 100644 --- a/help/en/docs/self-managed.md +++ b/help/en/docs/self-managed.md @@ -124,6 +124,34 @@ import glob glob.glob('/etc/*') ``` +Here are some reasons why `gvisor` sandboxing, as configured for +Grist, may fail, and what you can do to diagnose the problem. + +#### XSAVE not available + +Your processor may not be supported. On `x86_64`, Sandy Bridge +or later is needed. Check that the `XSAVE` processor flag is set. +Here's a quick way to test that: + +```sh +grep -q '\bxsave\b' /proc/cpuinfo && echo "XSAVE enabled" || echo "XSAVE missing" +``` + +#### PTRACE not available + +The `SYS_PTRACE` capability may not be available. If running +in docker, you could try explicitly granting it, if you are +comfortable with making it available: + +``` +docker run ... + --cap-add=SYS_PTRACE + ... +``` + +In some cloud environments such as AWS ECS, you may need to +explicitly list this capability in your container configuration. + ### How do I run Grist on a server? {: .tag-core .tag-ee } We suggest that you become familiar with all the other aspects of