Red Hat Bugzilla – Bug 802375
BIND cannot be shutdown correctly, if psearch is enabled and LDAP connect fails
Last modified: 2015-05-20 11:28:31 EDT
Created attachment 569371 [details]
Server was shutdown, but psearch watcher still runs and holds named process.
Description of problem:
If connection with LDAP server cannot be established, it is not possible to shutdown BIND correctly. (Example situation: Admin made mistake in LDAP server URI or server network/LDAP server is not functional.)
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Set uri parameter in /etc/named.conf to nonsense (ex. ldap://127.0.0.1:111)
2. run BIND (systemctl start named.service)
3. try to stop BIND via rndc stop or rndc halt
BIND still runs.
BIND was shutdown correctly.
Upstream ticket: https://fedorahosted.org/bind-dyndb-ldap/ticket/55
Fixed in upstream: https://fedorahosted.org/bind-dyndb-ldap/changeset/55d2886bb016adf3081a25eea616ce40f17d03e4
Persistent search feature postponed to 6.4, as discussed with Dmitri Pal and Jenny Galipeau.
Steps taken to verify:
# grep psearch /etc/named.conf
arg "psearch yes";
# service named status
CPUs found: 2
worker threads: 2
number of zones: 21
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is OFF
recursive clients: 0/0/1000
tcp clients: 0/100
server is up and running
named (pid 11954) is running...
# vim /etc/named.conf
=> Updated line to be:
#arg "uri ldapi://%2fvar%2frun%2fslapd-TESTRELM-COM.socket";
arg "uri ldapi://127.0.0.1:111";
# service named restart
Stopping named: .[ OK ]
Starting named: [ OK ]
# pgrep named
# rndc -V stop
create memory context
create socket manager
create task manager
create logging context
setting log tag
creating log channel
enabling log channel
decode base64 secret
using server 127.0.0.1 (127.0.0.1#953)
# service named status
rndc: connect failed: 127.0.0.1#953: connection refused
named dead but subsys locked
[root@ipaqa64vma ~]# pgrep named
Verified that BIND was shutdown correctly.
edited /etc/named.conf to go back to original line, and restarted named sucessfully after the test above.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.