BIND 10 trac2617, updated. 266bfcd67adafe326c13c6d835f5875628972d9f [2617] added "exiting" log message to those that don't have it until now.
BIND 10 source code commits
bind10-changes at lists.isc.org
Thu Jan 31 07:31:11 UTC 2013
The branch, trac2617 has been updated
via 266bfcd67adafe326c13c6d835f5875628972d9f (commit)
via 666395baa9b73aca0312787b683a7d3a96e7ca86 (commit)
via 8431fb8b25cde01d16bfdefdc52b2eb2b07cb756 (commit)
from ac23914ba629242fa651b4d68b61e9e5380c0643 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit 266bfcd67adafe326c13c6d835f5875628972d9f
Author: JINMEI Tatuya <jinmei at isc.org>
Date: Wed Jan 30 22:53:54 2013 -0800
[2617] added "exiting" log message to those that don't have it until now.
commit 666395baa9b73aca0312787b683a7d3a96e7ca86
Author: JINMEI Tatuya <jinmei at isc.org>
Date: Wed Jan 30 22:19:40 2013 -0800
[2617] logged shutdown event of cfgmgr
commit 8431fb8b25cde01d16bfdefdc52b2eb2b07cb756
Author: JINMEI Tatuya <jinmei at isc.org>
Date: Wed Jan 30 22:16:58 2013 -0800
[2617] reorder log message; some more comments and doc
-----------------------------------------------------------------------
Summary of changes:
src/bin/auth/auth_messages.mes | 3 ++
src/bin/auth/main.cc | 32 +++++++--------
src/bin/cmdctl/cmdctl.py.in | 2 +
src/bin/cmdctl/cmdctl_messages.mes | 3 ++
src/bin/msgq/msgq.py.in | 30 +++++++++++++-
src/bin/msgq/msgq_messages.mes | 53 +++++++++++++------------
src/bin/msgq/tests/msgq_test.py | 10 +++++
src/bin/stats/stats.py.in | 2 +
src/bin/stats/stats_httpd.py.in | 2 +
src/bin/stats/stats_httpd_messages.mes | 15 ++++---
src/bin/stats/stats_messages.mes | 3 ++
src/bin/xfrin/xfrin.py.in | 2 +
src/bin/xfrin/xfrin_messages.mes | 3 ++
src/bin/xfrout/xfrout.py.in | 3 +-
src/bin/xfrout/xfrout_messages.mes | 3 ++
src/bin/zonemgr/zonemgr.py.in | 2 +-
src/bin/zonemgr/zonemgr_messages.mes | 2 +-
src/lib/python/isc/config/cfgmgr.py | 3 +-
src/lib/python/isc/config/cfgmgr_messages.mes | 3 ++
19 files changed, 124 insertions(+), 52 deletions(-)
mode change 100644 => 100755 src/bin/stats/stats_httpd.py.in
-----------------------------------------------------------------------
diff --git a/src/bin/auth/auth_messages.mes b/src/bin/auth/auth_messages.mes
index d93da51..28b9623 100644
--- a/src/bin/auth/auth_messages.mes
+++ b/src/bin/auth/auth_messages.mes
@@ -312,6 +312,9 @@ been created and is initializing. The AUTH_SERVER_STARTED message will be
output when initialization has successfully completed and the server starts
accepting queries.
+% AUTH_SERVER_EXITING exiting
+The authoritative server is exiting.
+
% AUTH_SERVER_FAILED server failed: %1
The authoritative server has encountered a fatal error and is terminating. The
reason for the failure is included in the message.
diff --git a/src/bin/auth/main.cc b/src/bin/auth/main.cc
index e90d199..9b42628 100644
--- a/src/bin/auth/main.cc
+++ b/src/bin/auth/main.cc
@@ -44,6 +44,7 @@
#include <server_common/socket_request.h>
#include <boost/bind.hpp>
+#include <boost/scoped_ptr.hpp>
#include <sys/types.h>
#include <sys/socket.h>
@@ -152,10 +153,11 @@ main(int argc, char* argv[]) {
int ret = 0;
// XXX: we should eventually pass io_service here.
- Session* cc_session = NULL;
- Session* xfrin_session = NULL;
+ boost::scoped_ptr<AuthSrv> auth_server_; // placeholder
+ boost::scoped_ptr<Session> cc_session;
+ boost::scoped_ptr<Session> xfrin_session;
bool xfrin_session_established = false; // XXX (see Trac #287)
- ModuleCCSession* config_session = NULL;
+ boost::scoped_ptr<ModuleCCSession> config_session;
XfroutClient xfrout_client(getXfroutSocketPath());
SocketSessionForwarder ddns_forwarder(getDDNSSocketPath());
try {
@@ -167,7 +169,8 @@ main(int argc, char* argv[]) {
specfile = string(AUTH_SPECFILE_LOCATION);
}
- auth_server = new AuthSrv(xfrout_client, ddns_forwarder);
+ auth_server_.reset(new AuthSrv(xfrout_client, ddns_forwarder));
+ auth_server = auth_server_.get();
LOG_INFO(auth_logger, AUTH_SERVER_CREATED);
SimpleCallback* checkin = auth_server->getCheckinProvider();
@@ -179,7 +182,7 @@ main(int argc, char* argv[]) {
auth_server->setDNSService(dns_service);
LOG_DEBUG(auth_logger, DBG_AUTH_START, AUTH_DNS_SERVICES_CREATED);
- cc_session = new Session(io_service.get_io_service());
+ cc_session.reset(new Session(io_service.get_io_service()));
LOG_DEBUG(auth_logger, DBG_AUTH_START, AUTH_CONFIG_CHANNEL_CREATED);
// Initialize the Socket Requestor
isc::server_common::initSocketRequestor(*cc_session, AUTH_NAME);
@@ -191,18 +194,18 @@ main(int argc, char* argv[]) {
// updateConfig() for listen_on and in initializing TSIG keys below).
// Until then all operations on the CC session will take place
// synchronously.
- config_session = new ModuleCCSession(specfile, *cc_session,
- my_config_handler,
- my_command_handler, false);
+ config_session.reset(new ModuleCCSession(specfile, *cc_session,
+ my_config_handler,
+ my_command_handler, false));
LOG_DEBUG(auth_logger, DBG_AUTH_START, AUTH_CONFIG_CHANNEL_ESTABLISHED);
- xfrin_session = new Session(io_service.get_io_service());
+ xfrin_session.reset(new Session(io_service.get_io_service()));
LOG_DEBUG(auth_logger, DBG_AUTH_START, AUTH_XFRIN_CHANNEL_CREATED);
xfrin_session->establish(NULL);
xfrin_session_established = true;
LOG_DEBUG(auth_logger, DBG_AUTH_START, AUTH_XFRIN_CHANNEL_ESTABLISHED);
- auth_server->setXfrinSession(xfrin_session);
+ auth_server->setXfrinSession(xfrin_session.get());
// Configure the server. configureAuthServer() is expected to install
// all initial configurations, but as a short term workaround we
@@ -210,7 +213,7 @@ main(int argc, char* argv[]) {
// updateConfig().
// if server load configure failed, we won't exit, give user second
// chance to correct the configure.
- auth_server->setConfigSession(config_session);
+ auth_server->setConfigSession(config_session.get());
try {
configureAuthServer(*auth_server, config_session->getFullConfig());
auth_server->updateConfig(ElementPtr());
@@ -228,7 +231,7 @@ main(int argc, char* argv[]) {
config_session->addRemoteConfig("data_sources",
boost::bind(datasrcConfigHandler,
auth_server, &first_time,
- config_session,
+ config_session.get(),
_1, _2, _3),
false);
@@ -260,10 +263,7 @@ main(int argc, char* argv[]) {
config_session->removeRemoteConfig("data_sources");
}
- delete xfrin_session;
- delete config_session;
- delete cc_session;
- delete auth_server;
+ LOG_INFO(auth_logger, AUTH_SERVER_EXITING);
return (ret);
}
diff --git a/src/bin/cmdctl/cmdctl.py.in b/src/bin/cmdctl/cmdctl.py.in
index b026612..80064a9 100755
--- a/src/bin/cmdctl/cmdctl.py.in
+++ b/src/bin/cmdctl/cmdctl.py.in
@@ -650,4 +650,6 @@ if __name__ == '__main__':
if httpd:
httpd.shutdown()
+ logger.info(CMDCTL_EXITING)
+
sys.exit(result)
diff --git a/src/bin/cmdctl/cmdctl_messages.mes b/src/bin/cmdctl/cmdctl_messages.mes
index 5fbb430..32afce3 100644
--- a/src/bin/cmdctl/cmdctl_messages.mes
+++ b/src/bin/cmdctl/cmdctl_messages.mes
@@ -43,6 +43,9 @@ specific error is printed in the message.
This debug message indicates that the given command has been sent to
the given module.
+% CMDCTL_EXITING exiting
+The b10-cmdctl daemon is exiting.
+
% CMDCTL_NO_SUCH_USER username not found in user database: %1
A login attempt was made to b10-cmdctl, but the username was not known.
Users can be added with the tool b10-cmdctl-usermgr.
diff --git a/src/bin/msgq/msgq.py.in b/src/bin/msgq/msgq.py.in
index b63de49..9bf0b85 100755
--- a/src/bin/msgq/msgq.py.in
+++ b/src/bin/msgq/msgq.py.in
@@ -71,6 +71,15 @@ SPECFILE_LOCATION = SPECFILE_PATH + "/msgq.spec"
class MsgQReceiveError(Exception): pass
class MsgQCloseOnReceive(Exception):
+ '''Exception raised when reading data from a socket results in "shutdown.
+
+ This can be either getting 0-length data or via ECONNRESET socket.error
+ exception. This class holds whether it happens in the middle of reading
+ (i.e. after reading some) via partial_read parameter, which is set to True
+ if and only if so. This will be used by an upper layer cathing the
+ exception to distinguish severity of the event.
+
+ "'''
def __init__(self, reason, partial_read):
self.partial_read = partial_read
self.__reason = reason
@@ -328,8 +337,12 @@ class MsgQ:
def kill_socket(self, fd, sock):
"""Fully close down the socket."""
+ # Unregister events on the socket. Note that we don't have to do
+ # this for kqueue because the registered events are automatically
+ # deleted when the corresponding socket is closed.
if self.poller:
self.poller.unregister(sock)
+
self.subs.unsubscribe_all(sock)
lname = [ k for k, v in self.lnames.items() if v == sock ][0]
del self.lnames[lname]
@@ -341,11 +354,20 @@ class MsgQ:
def __getbytes(self, fd, sock, length, continued):
"""Get exactly the requested bytes, or raise an exception if
- EOF."""
+ EOF.
+
+ continued is set to True if this method is called to complete
+ already read data.
+ """
received = b''
while len(received) < length:
try:
data = sock.recv(length - len(received))
+
+ # If the remote client has closed the socket there seems to be
+ # two possible cases: getting ECONNRESET or receiving empty data.
+ # These cases are possible in normal operation, so we report them
+ # using MsgQCloseOnReceive.
except socket.error as err:
if err.errno == errno.ECONNRESET:
raise MsgQCloseOnReceive(str(err), continued)
@@ -382,6 +404,10 @@ class MsgQ:
try:
routing, data = self.read_packet(fd, sock)
except (MsgQReceiveError, MsgQCloseOnReceive) as err:
+ # If it's MsgQCloseOnReceive and that happens without reading
+ # any data, it basically means the remote clinet has closed the
+ # socket, so we log it as debug information. Otherwise, it's
+ # a somewhat unexpected event, so we consider it an "error".
if isinstance(err, MsgQCloseOnReceive) and not err.partial_read:
logger.debug(TRACE_BASIC, MSGQ_CLOSE_ON_RECV, fd)
else:
@@ -789,3 +815,5 @@ if __name__ == "__main__":
pass
msgq.shutdown()
+
+ logger.info(MSGQ_EXITING)
diff --git a/src/bin/msgq/msgq_messages.mes b/src/bin/msgq/msgq_messages.mes
index 94fb868..ad5c326 100644
--- a/src/bin/msgq/msgq_messages.mes
+++ b/src/bin/msgq/msgq_messages.mes
@@ -23,6 +23,31 @@
This is a debug message. The message queue has little bit of special handling
for the configuration manager. This special handling is happening now.
+% MSGQ_CLOSE_ON_RECV Reading from socket canceled as it's closed: FD=%1
+A debug message. The msgq daemon was notified of a read event on a
+socket, but its initial read operation failed because the remote
+client has closed its socket. This is possible in a normal operation
+when a module shuts down.
+
+% MSGQ_CLOSE_ON_SEND Sending to socket failed as already closed (okay to ignore on shutdown): FD=%1
+The msgq daemon tries to send some data to a client module, but it
+failed because the socket has been closed. This normally means the
+client terminates (for some reason - either gracefully or as a crash)
+while other modules try to send a message to the terminated module.
+Since msgq doesn't keep track of the status of client modules, this
+can happen and is not really an error for msgq; however, it can still
+be an unexpected event for the BIND 10 system as a whole in that this
+particular message is lost, so it's logged as a warning. If this
+message is logged for a running BIND 10 system, it's suggested to
+check other log messages; there may be an error from other modules
+reporting a missing response message. One common, less critical case
+where this message is logged is during shutdown. The ordering of
+process shutdown is basically arbitrary at this moment, so it's
+possible that some module tries to send a "quitting" message to some
+other module but the latter has already shut down. Such cases are
+generally non critical, but you may want to check other possible error
+messages.
+
% MSGQ_COMMAND Running command %1 with arguments %2
Debug message. The message queue received a command and it is running it.
@@ -34,6 +59,9 @@ the message queue version and version of the module.
% MSGQ_CONFIG_DATA Received configuration update for the msgq: %1
Debug message. The message queue received a configuration update, handling it.
+% MSGQ_EXITING exiting
+The msgq daemon is exiting.
+
% MSGQ_HDR_DECODE_ERR Error decoding header received from socket %1: %2
The socket with mentioned file descriptor sent a packet. However, it was not
possible to decode the routing header of the packet. The packet is ignored.
@@ -83,25 +111,6 @@ Debug message. This message includes the whole routing header of a packet.
There was a low-level error when sending data to a socket. The error is logged
and the corresponding socket is dropped.
-% MSGQ_CLOSE_ON_SEND Sending to socket failed as already closed (okay to ignore on shutdown): FD=%1
-The msgq daemon tries to send some data to a client module, but it
-failed because the socket has been closed. This normally means the
-client terminates (for some reason - either gracefully or as a crash)
-while other modules try to send a message to the terminated module.
-Since msgq doesn't keep track of the status of client modules, this
-can happen and is not really an error for msgq; however, it can still
-be an unexpected event for the BIND 10 system as a whole in that this
-particular message is lost, so it's logged as a warning. If this
-message is logged for a running BIND 10 system, it's suggested to
-check other log messages; there may be an error from other modules
-reporting a missing response message. One common, less critical case
-where this message is logged is during shutdown. The ordering of
-process shutdown is basically arbitrary at this moment, so it's
-possible that some module tries to send a "quitting" message to some
-other module but the latter has already shut down. Such cases are
-generally non critical, but you may want to check other possible error
-messages.
-
% MSGQ_SHUTDOWN Stopping Msgq
Debug message. The message queue is shutting down.
@@ -127,9 +136,3 @@ data structure.
% MSGQ_SUBS_NEW_TARGET Creating new target for subscription to group '%1' for instance '%2'
Debug message. Creating a new subscription. Also creating a new data structure
to hold it.
-
-% MSGQ_CLOSE_ON_RECV Reading from socket canceled as it's closed: FD=%1
-A debug message. The msgq daemon was notified of a read event on a
-socket, but its initial read operation failed because the remote
-client has closed its socket. This is possible in a normal operation
-when a module shuts down.
diff --git a/src/bin/msgq/tests/msgq_test.py b/src/bin/msgq/tests/msgq_test.py
index 1baaaa9..bcd9bc7 100644
--- a/src/bin/msgq/tests/msgq_test.py
+++ b/src/bin/msgq/tests/msgq_test.py
@@ -659,6 +659,7 @@ class SocketTests(unittest.TestCase):
for eno in [errno.EPIPE, errno.ECONNRESET, errno.ENOBUFS]:
self.__sock_error.errno = eno
self.__sock.ex_on_send = self.__sock_error
+ self.__killed_socket = None # clear any previuos value
self.assertEqual(None, self.__msgq._send_data(self.__sock,
self.__data))
self.assertEqual((42, self.__sock), self.__killed_socket)
@@ -703,9 +704,13 @@ class SocketTests(unittest.TestCase):
expected_errors = 0
expected_debugs = 0
+ # if socket.recv() fails due to socket.error, it will be logged
+ # as error or debug depending on the errno. In either case the socket
+ # will be killed.
for eno in [errno.ENOBUFS, errno.ECONNRESET]:
self.__sock_error.errno = eno
self.__sock.recv_result = self.__sock_error
+ self.__killed_socket = None # clear any previuos value
self.__msgq.process_packet(42, self.__sock)
self.assertEqual((42, self.__sock), self.__killed_socket)
if eno == errno.ENOBUFS:
@@ -715,8 +720,13 @@ class SocketTests(unittest.TestCase):
self.assertEqual(expected_errors, self.__logger.error_called)
self.assertEqual(expected_debugs, self.__logger.debug_called)
+ # if socket.recv() returns empty data, the result depends on whether
+ # there's any preceding data; in the second case below, at least
+ # 6 bytes of data will be expected, and the second call to our faked
+ # recv() returns empty data. In that case it will logged as error.
for recv_data in [b'', b'short']:
self.__sock.recv_result = recv_data
+ self.__killed_socket = None
self.__msgq.process_packet(42, self.__sock)
self.assertEqual((42, self.__sock), self.__killed_socket)
if len(recv_data) == 0:
diff --git a/src/bin/stats/stats.py.in b/src/bin/stats/stats.py.in
index 7123c53..3692814 100755
--- a/src/bin/stats/stats.py.in
+++ b/src/bin/stats/stats.py.in
@@ -696,3 +696,5 @@ if __name__ == "__main__":
sys.exit(1)
except KeyboardInterrupt as kie:
logger.info(STATS_STOPPED_BY_KEYBOARD)
+
+ logger.info(STATS_EXITING)
diff --git a/src/bin/stats/stats_httpd.py.in b/src/bin/stats/stats_httpd.py.in
old mode 100644
new mode 100755
index 736029b..659f8f4
--- a/src/bin/stats/stats_httpd.py.in
+++ b/src/bin/stats/stats_httpd.py.in
@@ -631,3 +631,5 @@ if __name__ == "__main__":
sys.exit(1)
except KeyboardInterrupt as kie:
logger.info(STATSHTTPD_STOPPED_BY_KEYBOARD)
+
+ logger.info(STATSHTTPD_EXITING)
diff --git a/src/bin/stats/stats_httpd_messages.mes b/src/bin/stats/stats_httpd_messages.mes
index 62fbd45..511289f 100644
--- a/src/bin/stats/stats_httpd_messages.mes
+++ b/src/bin/stats/stats_httpd_messages.mes
@@ -32,10 +32,19 @@ address and port number.
Debug message indicating that the stats-httpd module is disconnecting
from the command and control bus.
+% STATSHTTPD_EXITING exiting
+The stats HTTP server is exiting.
+
% STATSHTTPD_HANDLE_CONFIG reading configuration: %1
The stats-httpd daemon has received new configuration data and will now
process it. The (changed) data is printed.
+% STATSHTTPD_HTTPLOG %1 %2
+Debug HTTP log message. These are the messages logged by the http server
+instance. For most logs, the message shows HTTP client and query
+information like HTTP method, URI, and status code, but the http server
+can also log other information, such as extended status reports.
+
% STATSHTTPD_RECEIVED_SHUTDOWN_COMMAND shutdown command received
A shutdown command was sent to the stats-httpd module, and it will
now shut down.
@@ -96,9 +105,3 @@ configuration is unknown. The new configuration is ignored, and an
error is sent back. As possible cause is that there was an upgrade
problem, and the stats-httpd version is out of sync with the rest of
the system.
-
-% STATSHTTPD_HTTPLOG %1 %2
-Debug HTTP log message. These are the messages logged by the http server
-instance. For most logs, the message shows HTTP client and query
-information like HTTP method, URI, and status code, but the http server
-can also log other information, such as extended status reports.
diff --git a/src/bin/stats/stats_messages.mes b/src/bin/stats/stats_messages.mes
index 3960c26..b6f0b16 100644
--- a/src/bin/stats/stats_messages.mes
+++ b/src/bin/stats/stats_messages.mes
@@ -24,6 +24,9 @@ The stats module was unable to connect to the BIND 10 command and
control bus. A likely problem is that the message bus daemon
(b10-msgq) is not running. The stats module will now shut down.
+% STATS_EXITING exiting
+The stats module process is exiting.
+
% STATS_RECEIVED_INVALID_STATISTICS_DATA received invalid statistics data from %1
Invalid statistics data has been received from the module while
polling and it has been discarded.
diff --git a/src/bin/xfrin/xfrin.py.in b/src/bin/xfrin/xfrin.py.in
index 8daf62f..66fbc52 100755
--- a/src/bin/xfrin/xfrin.py.in
+++ b/src/bin/xfrin/xfrin.py.in
@@ -1738,5 +1738,7 @@ def main(xfrin_class, use_signal=True):
if xfrind:
xfrind.shutdown()
+ logger.info(XFRIN_EXITING)
+
if __name__ == '__main__':
main(Xfrin)
diff --git a/src/bin/xfrin/xfrin_messages.mes b/src/bin/xfrin/xfrin_messages.mes
index 48cb23a..20959e2 100644
--- a/src/bin/xfrin/xfrin_messages.mes
+++ b/src/bin/xfrin/xfrin_messages.mes
@@ -60,6 +60,9 @@ error is given in the log message.
There was an error opening a connection to the master. The error is
shown in the log message.
+% XFRIN_EXITING exiting
+The xfrin daemon is exiting.
+
% XFRIN_GOT_INCREMENTAL_RESP got incremental response for %1
In an attempt of IXFR processing, the beginning SOA of the first difference
(following the initial SOA that specified the final SOA for all the
diff --git a/src/bin/xfrout/xfrout.py.in b/src/bin/xfrout/xfrout.py.in
index f869955..c1885a9 100755
--- a/src/bin/xfrout/xfrout.py.in
+++ b/src/bin/xfrout/xfrout.py.in
@@ -1274,7 +1274,7 @@ if '__main__' == __name__:
xfrout_server = XfroutServer()
xfrout_server.run()
except KeyboardInterrupt:
- logger.INFO(XFROUT_STOPPED_BY_KEYBOARD)
+ logger.info(XFROUT_STOPPED_BY_KEYBOARD)
except SessionError as e:
logger.error(XFROUT_CC_SESSION_ERROR, str(e))
except ModuleCCSessionError as e:
@@ -1287,3 +1287,4 @@ if '__main__' == __name__:
if xfrout_server:
xfrout_server.shutdown()
+ logger.info(XFROUT_EXITING)
diff --git a/src/bin/xfrout/xfrout_messages.mes b/src/bin/xfrout/xfrout_messages.mes
index d48aa24..6b88d27 100644
--- a/src/bin/xfrout/xfrout_messages.mes
+++ b/src/bin/xfrout/xfrout_messages.mes
@@ -32,6 +32,9 @@ configuration manager b10-cfgmgr is not running.
The xfrout process encountered an error when installing the configuration at
startup time. Details of the error are included in the log message.
+% XFROUT_EXITING exiting
+The xfrout daemon is exiting.
+
% XFROUT_FETCH_REQUEST_ERROR socket error while fetching a request from the auth daemon
There was a socket error while contacting the b10-auth daemon to
fetch a transfer request. The auth daemon may have shutdown.
diff --git a/src/bin/zonemgr/zonemgr.py.in b/src/bin/zonemgr/zonemgr.py.in
index 0412e3f..7fa5f7d 100755
--- a/src/bin/zonemgr/zonemgr.py.in
+++ b/src/bin/zonemgr/zonemgr.py.in
@@ -714,4 +714,4 @@ if '__main__' == __name__:
if zonemgrd and zonemgrd.running:
zonemgrd.shutdown()
- logger.debug(DBG_START_SHUT, ZONEMGR_SHUTDOWN)
+ logger.info(ZONEMGR_SHUTDOWN)
diff --git a/src/bin/zonemgr/zonemgr_messages.mes b/src/bin/zonemgr/zonemgr_messages.mes
index 4f58271..a9cc094 100644
--- a/src/bin/zonemgr/zonemgr_messages.mes
+++ b/src/bin/zonemgr/zonemgr_messages.mes
@@ -114,7 +114,7 @@ connecting to the command channel daemon. The most usual cause of this
problem is that the daemon is not running.
% ZONEMGR_SHUTDOWN zone manager has shut down
-A debug message, output when the zone manager has shut down completely.
+The zone manager has shut down completely.
% ZONEMGR_STARTED zonemgr started
This informational message is output by zonemgr when all initialization
diff --git a/src/lib/python/isc/config/cfgmgr.py b/src/lib/python/isc/config/cfgmgr.py
index 9563cab..cb7f1ea 100644
--- a/src/lib/python/isc/config/cfgmgr.py
+++ b/src/lib/python/isc/config/cfgmgr.py
@@ -551,7 +551,7 @@ class ConfigManager:
def run(self):
"""Runs the configuration manager."""
self.running = True
- while (self.running):
+ while self.running:
# we just wait eternally for any command here, so disable
# timeouts for this specific recv
self.cc.set_timeout(0)
@@ -566,3 +566,4 @@ class ConfigManager:
# Only respond if there actually is something to respond with
if answer is not None:
self.cc.group_reply(env, answer)
+ logger.info(CFGMGR_STOPPED_BY_COMMAND)
diff --git a/src/lib/python/isc/config/cfgmgr_messages.mes b/src/lib/python/isc/config/cfgmgr_messages.mes
index 8701db3..37ba889 100644
--- a/src/lib/python/isc/config/cfgmgr_messages.mes
+++ b/src/lib/python/isc/config/cfgmgr_messages.mes
@@ -61,6 +61,9 @@ error is given. The most likely cause is that the system does not have
write access to the configuration database file. The updated
configuration is not stored.
+% CFGMGR_STOPPED_BY_COMMAND received shutdown command, shutting down
+The configuration manager received a shutdown command, and is exiting.
+
% CFGMGR_STOPPED_BY_KEYBOARD keyboard interrupt, shutting down
There was a keyboard interrupt signal to stop the cfgmgr daemon. The
daemon will now shut down.
More information about the bind10-changes
mailing list