Bug 712 - unbound-anchor appears to not fsync root.key
unbound-anchor appears to not fsync root.key
Status: RESOLVED FIXED
Product: unbound
Classification: Unclassified
Component: server
1.5.4
x86_64 FreeBSD
: P5 major
Assigned To: unbound team
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2015-10-22 03:51 CEST by Chris Buechler
Modified: 2015-10-23 05:20 CEST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Buechler 2015-10-22 03:51:14 CEST
We've had a few pfSense users report problems with Unbound failing to start with "error: failed to read /root.key". Upon inspection, in these cases the root.key file ends up containing portions of other files in the same root parent directory (/var/ in our case, Unbound uses /var/unbound) which have been recently written. That's typical of what happens on FreeBSD with a file that's written out without a fsync afterwards and you lose power shortly after the write. 

It's not all that easily replicable, but it appears doing a fsync on root.key after 'unbound-anchor -a root.key' is run prevents this from occurring. 

our bug ticket: 
https://redmine.pfsense.org/issues/5334

This has been happening across all Unbound versions we've used, starting with 1.4.x versions but mostly 1.5.1 and newer (current 1.5.4 from the last couple user reports, but I don't see any relevant changes in 1.5.5 and 1.5.6).
Comment 1 Wouter Wijngaards 2015-10-22 09:07:41 CEST
Hi Chris,

Thank you for the report.  I have added fflush(file) and fsync(fileno(file)) before the fclose(file) calls for root.key.  I hope that will remove the issue.

You are correct that there has been no fsync call since the initial code.

Best regards, Wouter
Comment 2 Chris Buechler 2015-10-23 05:20:52 CEST
Thanks! Looks like that should take care of it, appreciate the quick response.