Tmpfs directory inside a snap (like `/run`)

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 $SNAPCOMMON or $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)

2 Likes

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 …

3 Likes