XDG_RUNTIME_DIR, etc

Loïc Minier loic.minier at ubuntu.com
Mon Aug 17 22:32:05 UTC 2015


All great points from Ted and you; in fact, I've been bitten by the
variable socket path issue both between apps from the same snap and between
snaps that would like to IPC each other, so it's valuable to have a stable
tree to reference (e.g. between a snap and a framework).

I'd like to add that runtime performance is also important; mounts and file
juggling/complex startup might slow down stuff for trivial commands that
might be invoked a bunch of times, so a simple and lean startup is
desirable too.

Perhaps the expensive per-app startup with mounts and stuff only has to be
run once per device boot and the app is kept ready to run until next reboot?

Cheers,

On Fri, Aug 14, 2015 at 4:03 PM, John Lenton <john.lenton at canonical.com>
wrote:

> we're currently not exposing a runtime dir to snaps, and that together
> with our private random tmpdirs mean we don't have a good story for a
> snap shipping a service that creates a socket and a binary that wants
> to communicate with that service over that socket; people are using
> the data dir for now, but it's not ideal.
>
> I think we should:
>
> * remove the random component from the tmpdir (this has security
> implications around the predictable tmpdir creation, but I think it's
> doable?)
>
> * set up a private per-package system runtime dir mount, similarly to
> what we do for /tmp (ie make it a sub of /run/
>
> * set up a private per-package user runtime dir mount, under
> /run/user/$UID/package.etc
>
> does this all make sense, or am i overthinking it?
>
> --
> snappy-devel mailing list
> snappy-devel at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/snappy-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snappy-devel/attachments/20150818/07861ba0/attachment.html>


More information about the snappy-devel mailing list