In RHOSO, due to deficiency in the signal handler used for OVN ovsdb-server pod, we caught the following scenario:

• pod starts by creating the db file with ovsdb-tool
• ovsdb-tool opens the file (creating an empty file)
• ovsdb-tool gets SIGKILLed before it has a chance to add a RAFT config record to the file and flush it to disc
• next time the pod is started, it detects that there is a db file on disc
• it attempts to start with the file, but the file has bad format (no magic headers)

The culprit is that ovs-lib.in code assumes that if the file exists, that it's a valid db file. I think if the file is empty, it should handle it the same way as if the file does not exist at all - by initializing it anew.

Another path to resolve is to provide guarantees that ovsdb-tool will never leave a file with invalid format on disc. This can be achieved by e.g. generating the new db file as a temporary file, flushing the initial records, then (atomically) renaming the file to the desired location. This should guarantee that the file is never in inconsistent state, regardless of when ovsdb-tool process may be killed.