Ayush Ranjan

This is a known deficiency: https://github.com/google/gvisor/blob/b09abbed21fcba6057ff1bdae1aebd10d2c2a8e6/pkg/sentry/fsimpl/proc/tasks_files.go#L187-L195 > I think tools like htop don't work (the CPU usage shown is just always zero), though I'm not 100% sure that /proc/stat is...

This is still the case AFAICT. If anyone wants to take a crack at this, you should start looking [here](https://cs.opensource.google/gvisor/gvisor/+/master:pkg/sentry/fsimpl/gofer/gofer.go;l=967-975;drc=35dab382a68ebf4b02092ee28118b8297ad54fa6). See the usages of this field. What @fvoznika suggests above...

@avagin is this still the case?

xattr syscalls are supported. Only runsc fsgofer doesn't support them. We will add support if need arises. For now, it is WAI.

Seemed to be due to `no space left on device` errors.

Thanks, I can repro this. `runsc.log.*.checkpoint.txt`: ``` I0126 05:14:41.437771 530689 main.go:199] **************** gVisor **************** D0126 05:14:41.437836 530689 state_file.go:78] Load container, rootDir: "/var/run/runsc", id: {SandboxID: ContainerID:hello}, opts: {Exact:false SkipCheck:false TryLock:false RootContainer:false}...

I think I understand the issue. It is due to the following deadlock: - `sudo runsc run hello` is run in attached mode. So the parent `runsc run` process waits...

@amurchick thanks for the investigation and the proposed fix. Do you mind sending a PR for this? And if possible could you add a test for this?

@avagin do you think we can revive this patch? It will fix #2010, which has some perf benefits.

https://github.com/golang/go/commit/ecfce58965da6017e02f5fc5c03eda52fc41c8d6 must have helped with this. Is this still an issue?