We’ve run into an issue with MicroK8s where containerd expects to write things into a tmpfs, specifically
/run (thus is deleted at system boot, see https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s15.html). Obviously we have the option of putting that data into either
$SNAPDATA, which causes containerd to fail during a system reboot.
We can write some workarounds into the start and stop hooks to deal with this, but I feel like having a sort of
$SNAPRUN dir, that’s deleted at snap remove or system reboot would be a great idea. Is this something that’s been considered?
You can use
/tmp for temporary data, or for
/run-style data you can use
/run/snap.$SNAP_INSTANCE_NAME/ (that will need to be created with a suitable
mkdir before it can be used)
ah thanks @lucyllewy, does this work across classic and strict the same way?
Classic snaps have full access to the entire system so these restrictions don’t apply.
Yeah, maybe I should rephrase that. Is an interface needed for strict, or should it have RW access to
/run/snap.$SNAP_INSTANCE_NAME/ by default?
this is allowed by default … though as daniel said, you can also just use /tmp … in snaps /tmp is a private per-snap dir …