Snappy hw-assign doesn't restart affected services
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| | Snappy |
High
|
Unassigned | ||
Bug Description
Scenario:
You install a snap that requires access to some hardware resource, e.g. /dev/i2c-1. Since it has not been granted access to that resource via hw-assign, when it starts it tries to open it, errors out, and dies. This is all transparent to you, the installer. You know now that it's installed it needs that hardware provisioned for it, so you run
sudo snappy hw-assign <snap> /dev/i2c-1
Expected results:
The app now has access to the desired resource and runs normally.
Actual results:
Nothing changes. If the app died from the inability to open the resource, it's still dead. If the app instead just hung, it's still hanging. If the app even did a lazy retry to open the resource, those retries would still fail since that instance is still confined.
hw-assign should restart the services it affects, since there's no other way for that application to obtain that resource.
| description: | updated |
| description: | updated |
| Jamie Strandboge (jdstrand) wrote : | #1 |
| Changed in snappy: | |
| status: | New → Triaged |
| importance: | Undecided → Medium |
| Michael Vogt (mvo) wrote : | #2 |
<mvo> maybe we need to raise the priority of this one
or at least print some warning as a stop-gap
| Changed in snappy: | |
| importance: | Medium → High |
| Michael Vogt (mvo) wrote : | #3 |
We do not have hw-assign anymore in snappy 16 so I mark this bug as won't fix. Please reopen if there are similar issues with interfaces.
| Changed in snappy: | |
| status: | Triaged → Won't Fix |


"those retries would still fail since that instance is still confined" possibly needs clarification-- the apparmor confinement can be updated for a running process just fine, and we do this. The problems comes in that ubuntu- core-launcher only conditionally sets up a devices cgroup if hw-assign (or oem/gadget yaml) _was_ used prior to launch. In the case of a service that is started before hw-assign is run, nothing sets up this cgroup for the service and makes it enter it (I'm not sure you can apply a cgroup after the fact anyway), so the service needs to do a full stop/start after hw-assign (ie, a HUP is not enough) so the launcher can do its job. This makes sense in the general case since most apps are probably not going to properly handle not having access to a device and then later having it.