$SNAP_APP_USER_DATA_PATH points to non-existing directory for services

[Kyle Fazzari]

For a Snappy binary, $SNAP_APP_USER_DATA_PATH is created within the binary wrapper right before the binary is launched[1]. However, no such logic exists for services, where the $SNAP_APP_USER_DATA_PATH resolves to /root/apps/... . This means that if a Snappy service tries to use $SNAP_APP_USER_DATA_PATH, it's trying to use a directory that doesn't exist. This leads services to either fail or try to create /root/apps, which obviously can't happen.

[1]: https://github.com/ubuntu-core/snappy/blob/master/snappy/click.go#L87

[Kyle Fazzari (kyrofa)]

The proposed fix is to remap $SNAP_APP_USER_DATA_PATH to $SNAP_APP_DATA_PATH, which makes more sense for services to write to anyway.

[Kyle Fazzari (kyrofa)]

Fix here: https://github.com/ubuntu-core/snappy/pull/269

[Kyle Fazzari (kyrofa)]

This remapping proposal leads to the possibility of a service trying to save a file named the same to both the user data path and the data path, resulting in a clash. A better solution would be to extract the user data path creation from the wrapper and add such functionality to ubuntu-core-launcher instead. This would simply make the user data path a valid directory for both services and binaries.

[Kyle Fazzari (kyrofa)]

This bug is a blocker when it comes to ROS services created with Snapcraft, since they require a working $SNAP_USER_DATA directory.

[Jamie Strandboge (jdstrand)]

This is fixed in launcher trunk and uploaded to the Ubuntu archive and the image ppa for xenial.

[Zygmunt Krynicki (zyga)]

The 15.04 series is EOLd and not developed anymore.