Bug 742 - [RFC 5011] When the disk is full, the autokey is erased with an empty file
[RFC 5011] When the disk is full, the autokey is erased with an empty file
Status: ASSIGNED
Product: unbound
Classification: Unclassified
Component: server
1.5.7
x86_64 Linux
: P5 normal
Assigned To: unbound team
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2016-01-29 07:27 CET by Stéphane Bortzmeyer
Modified: 2016-01-29 09:03 CET (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 Stéphane Bortzmeyer 2016-01-29 07:27:20 CET
I run Unbound with RFC 5011 enabled:

server:
  auto-trust-anchor-file: autokey/yeti-key.key

When the disk happens to be full, Unbound, probably trying to write a new key, left a file of size 0.

After that, Unbound could no longer start:

Jan 28 08:04:10 dahu1 unbound[1613]: [1613:0] notice: init module 0: validator
Jan 28 08:04:10 dahu1 unbound[1613]: [1613:0] error: failed to read autokey/yeti-key.key
Jan 28 08:04:10 dahu1 unbound[1613]: [1613:0] error: error reading auto-trust-anchor-file: autokey/yeti-key.key
Jan 28 08:04:10 dahu1 unbound[1613]: [1613:0] error: validator: error in trustanchors config
Jan 28 08:04:10 dahu1 unbound[1613]: [1613:0] error: validator: could not apply configuration settings.
Jan 28 08:04:10 dahu1 unbound[1613]: [1613:0] error: module init for module validator failed
Jan 28 08:04:10 dahu1 unbound[1613]: [1613:0] fatal error: failed to setup modules
Jan 28 08:05:20 dahu1 unbound[1641]: [1641:0] notice: init module 0: validator
Jan 28 08:05:20 dahu1 unbound[1641]: [1641:0] notice: init module 1: iterator
Jan 28 08:05:20 dahu1 unbound[1641]: [1641:0] info: start of service (unbound 1.5.7).
Comment 1 Wouter Wijngaards 2016-01-29 09:03:31 CET
Hi Stephane,

Did you report the version correctly?  There was a bug in older versions that had this issue, but I fixed it, it first writes to a temporary file yourname.pidno-threadno, and if that is successful it renames the file to the original name.

These errors are fatal errors, so if it could not write the file it would have exited.  So, to unbound, the open of the new file and all the write commands completed successfully and the rename succeeded too ...

Do you have any errors in log?

Best regards, Wouter