lock file is deleted on exit even if lock acquisition failed

Summary

If BIND is started and uses a lock file, either through the "lock-file" statement or the "-X" command line parameter, a following invocation will remove the lock file on exit. This means that a following invocation will start as a lock file will not be present.

BIND version used

BIND 9.19.17 (Development Release) <id:464cf8c>
running on Linux x86_64 6.0.12-100.fc35.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Dec 8 16:53:55 UTC 2022
built by make with  '--enable-fixed-rrset' '--enable-dnstap' '--enable-querytrace=yes' '--with-openssl' '--with-libxml2' '--with-json-c' '--enable-full-report'
compiled by GCC 11.3.1 20220421 (Red Hat 11.3.1-3)
compiled with OpenSSL version: OpenSSL 1.1.1q  FIPS 5 Jul 2022
linked to OpenSSL version: OpenSSL 1.1.1q  FIPS 5 Jul 2022
compiled with libuv version: 1.44.2
linked to libuv version: 1.44.2
compiled with liburcu version: 0.13.0
compiled with jemalloc version: 5.2.1
compiled with libnghttp2 version: 1.45.1
linked to libnghttp2 version: 1.45.1
compiled with libxml2 version: 2.9.14
linked to libxml2 version: 20914
compiled with json-c version: 0.15
linked to json-c version: 0.15
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
compiled with protobuf-c version: 1.4.0
linked to protobuf-c version: 1.4.0
threads support is enabled
DNSSEC algorithms: RSASHA1 NSEC3RSASHA1 RSASHA256 RSASHA512 ECDSAP256SHA256 ECDSAP384SHA384 ED25519 ED448
DS algorithms: SHA-1 SHA-256 SHA-384
HMAC algorithms: HMAC-MD5 HMAC-SHA1 HMAC-SHA224 HMAC-SHA256 HMAC-SHA384 HMAC-SHA512
TKEY mode 2 support (Diffie-Hellman): no
TKEY mode 3 support (GSS-API): yes

default paths:
  named configuration:  /usr/local/etc/named.conf
  rndc configuration:   /usr/local/etc/rndc.conf
  nsupdate session key: /usr/local/var/run/named/session.key
  named PID file:       /usr/local/var/run/named/named.pid
  named lock file:      /usr/local/var/run/named/named.lock

Also reported on BIND 9.18.19

Steps to reproduce

using the configuration below:

1. Start an initial BIND process:
   named -c /etc/named.conf

2. Start a second BIND process - this will fail as it see's the lock file created by the running BIND process.
   named -c /etc/named.conf

3. Start a third BIND process
   named -c /etc/named.conf

This should also fail, but as the second BIND process removed the lock file the process starts named -c /etc/named.conf

Now there are two running BIND processes.

What is the current bug behavior?

Two BIND processes running simultaneously

What is the expected correct behavior?

One the BIND process that creates the lock file should run

Relevant configuration files

options {
   directory "/home/named";
   lock-file "/home/named/named.lock";
   recursion yes;
   allow-query { any; };
   empty-zones-enable yes;
   };

logging {
   channel example-log {
      file "/home/named/log/example.log";
      severity info;
   };
   category default {
   example-log;
      };
   };

Relevant logs and/or screenshots

Possible fixes

move the unlink call to a more suitable place