[PUP-8548] File isn't synced to disk Created: 2018/03/14 Updated: 2018/05/15 Resolved: 2018/05/15
|Labels:||container, triaged, type_and_provider|
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
|Template:||PUP Bug Template customfield_10700 241203|
|Method Found:||Needs Assessment|
|QA Risk Assessment:||Needs Assessment|
We're running our Puppet tests with `apply` in docker containers. From time to time we're seeing strange errors which seem to come from apt source list files not being on disk as apt::update is triggered.
Apt doesn't know anything about the additional repository:
But Puppet tells us that the file got placed before triggering apt::update, so apt should know about the repository:
This seems to be a sync to disk problem. Futher debugging in https://github.com/puppetlabs/puppet/blob/master/lib/puppet/type/file/content.rb#L124 showed that the `sync` (https://ruby-doc.org/core-2.2.2/IO.html#method-i-sync) parameter of the file object is set to 'false'. Should this be set to true?
|Comment by Matthias Baur [ 2018/03/14 ]|
Hmm just found https://github.com/puppetlabs/puppet/blob/master/lib/puppet/type/file.rb#L860-L863 so seem like the flush to the disk really is happening. Still we see this error from time to time, do you have any idea where this might come from?
|Comment by Branan Riley [ 2018/05/14 ]|
Is your `/etc/` mounted through any sort of indirection? I wonder if this is actually something in the underlying filesystem that's reporting stale data back.
|Comment by Matthias Baur [ 2018/05/15 ]|
Not exactly, '/' is on one partition on the Docker Host and in the Docker Container. We did a lot of changes on our CI lately including changing the Docker storage driver from aufs to overlay2, switching from Jenkins to Gitlab CI, ...
Still, the issue seems kind of odd.
|Comment by Branan Riley [ 2018/05/15 ]|
Doing a bit of googling I see several old and closed issues against Docker related to filesystem issues (mostly at build time) - if there was some sort of FS issue under the hood in Docker, it could definitely also affect puppet runs.
Since you can't reproduce this in your current set of deployments, I'm going to go ahead and close for now. If you can come up with any new data that makes it look like a Puppet issue again, feel free to reopen.