We used apparmor_parser to reload it, but we still got the error message.
We didn’t find the Greengrass logs under $SNAP_DATA/ggc-writable even though populating that directory is one of the first things Greengrass does on startup. That and the fact that we couldn’t run --shell into the snap indicates that there’s something fundamentally broken with the way permissions are granted.
AWS IoT Greengrass also provides containerized environments that run the AWS the AWS IoT Greengrass Core software on your core device, but it doesn’t 18.104.22.168 2996 latest/stable aws✓ classic core 16 -2.48 10444 latest/stable For examples, if you specify --channel= 1.8 . x
The odd thing here is that it’s snap-confine which is trying to read the cgroups, not Greengrass. We aren’t even getting to the point where greengrassd runs since snap-confine is stuck and dies. This is especially peculiar given that snap-confine should also be allowed to read these cgroups paths:
Can you provide the output of
sudo SNAP_CONFINE_DEBUG=1 snap run aws-iot-greengrass.greengrassd
I can reproduce the /sys/block denial in an Ubuntu Core 16 VM with revision 4 on amd64 but the daemon still runs and my lambdas are running properly for me. I’m fairly certain it’s just noise given that it’s from the mount process.
I provided my certs via snap set aws-iot-greengrass gg-certs=$(pwd)/certs.tgz and the daemon started up properly, and after deploying my group with the hello-world python lambda I could see the messages sent to the Test subscription.
The permission error doesn’t always occur. As far as we can tell, it might be avoided by creating ggc_user/ggc_group ahead of time, even if GG isn’t going to use it. It might also be avoided if the group has at least one successful deployment (even if it is on another machine).
For now, we’ve solved the issues being faced, but we highly recommend that people use the supported versions of the GG snap.