Came across an interesting behavior I though I would pass along.
I have an existing directory on my internal-golden image that contains a couple programs. Since there were only 2 files modified in this directory I thought I would just modify my rootfs_overlay to contain these new files and create a release (as opposed to recapturing the entire internal-golden image).
So I created this directory on my build server in my rootfs_overlay folder and added the updated programs.
All worked perfect(wait for it)! I deployed my new artifact and my devices updated without issue and the new programs were working just fine.
I would have never discovered the issue if I was not using the built in os functionality of logroate in that directory. I simply noticed that my logfile was not being rotated in this directory. My log rotation works perfectly on the internal-golden and my development environment.
So what happened? I discovered that the directory created on my build server in my rootfs_overlay directory gives the default permissions of 775 for that directory. Both my internal-golden and my development environment the permissions are 755.
Turns out that logrotate (I ran it manually in verbose mode) does not like the 775 permissions on this directory and calls it “insecure permissions” and won’t touch the logs. As soon as I changed it back to 755 permissions, logrotate work perfectly.
I’m making the assumption that if I had copied over the entire source directory (instead of creating it) in the first place, it would have kept the correct permissions.
Glad I made this discovery as logrotate is very important for IoT logs and such!
Just thought I’d pass this along. Nothing to really fix, it’s just up to the user to make sure any directories created in the rootfs_overlay have permissions set as the user needs, VERY IMPORTANT 
,