[2672] Remove ERROR from various message IDs where not applicable

src/bin/auth/auth_messages.mes

@@ -14,7 +14,7 @@
 
 $NAMESPACE isc::auth
 
-% AUTH_AXFR_ERROR error handling AXFR request: %1
+% AUTH_AXFR_PROBLEM error handling AXFR request: %1
 This is a debug message produced by the authoritative server when it
 has encountered an error processing an AXFR request. The message gives
 the reason for the error, and the server will return a SERVFAIL code to
@@ -232,13 +232,13 @@ This is a debug message produced by the authoritative server when it receives
 a NOTIFY packet but the XFRIN process is not running. The packet will be
 dropped and nothing returned to the sender.
 
-% AUTH_PACKET_PARSE_ERROR unable to parse received DNS packet: %1
+% AUTH_PACKET_PARSE_FAILED unable to parse received DNS packet: %1
 This is a debug message, generated by the authoritative server when an
 attempt to parse a received DNS packet has failed due to something other
 than a protocol error. The reason for the failure is given in the message;
 the server will return a SERVFAIL error code to the sender.
 
-% AUTH_PACKET_PROTOCOL_ERROR DNS packet protocol error: %1. Returning %2
+% AUTH_PACKET_PROTOCOL_FAILURE DNS packet protocol error: %1. Returning %2
 This is a debug message, generated by the authoritative server when an
 attempt to parse a received DNS packet has failed due to a protocol error.
 The reason for the failure is given in the message, as is the error code

src/bin/auth/auth_srv.cc

@@ -526,13 +526,13 @@ AuthSrv::processMessage(const IOMessage& io_message, Message& message,
         // Parse the message.
         message.fromWire(request_buffer);
     } catch (const DNSProtocolError& error) {
-        LOG_DEBUG(auth_logger, DBG_AUTH_DETAIL, AUTH_PACKET_PROTOCOL_ERROR)
+        LOG_DEBUG(auth_logger, DBG_AUTH_DETAIL, AUTH_PACKET_PROTOCOL_FAILURE)
                   .arg(error.getRcode().toText()).arg(error.what());
         makeErrorMessage(impl_->renderer_, message, buffer, error.getRcode());
         impl_->resumeServer(server, message, stats_attrs, true);
         return;
     } catch (const Exception& ex) {
-        LOG_DEBUG(auth_logger, DBG_AUTH_DETAIL, AUTH_PACKET_PARSE_ERROR)
+        LOG_DEBUG(auth_logger, DBG_AUTH_DETAIL, AUTH_PACKET_PARSE_FAILED)
                   .arg(ex.what());
         makeErrorMessage(impl_->renderer_, message, buffer, Rcode::SERVFAIL());
         impl_->resumeServer(server, message, stats_attrs, true);
@@ -725,7 +725,7 @@ AuthSrvImpl::processXfrQuery(const IOMessage& io_message, Message& message,
             xfrout_connected_ = false;
         }
 
-        LOG_DEBUG(auth_logger, DBG_AUTH_DETAIL, AUTH_AXFR_ERROR)
+        LOG_DEBUG(auth_logger, DBG_AUTH_DETAIL, AUTH_AXFR_PROBLEM)
                   .arg(err.what());
         makeErrorMessage(renderer_, message, buffer, Rcode::SERVFAIL(),
                          tsig_context);

src/bin/ddns/ddns.py.in

@@ -536,7 +536,7 @@ class DDNSServer:
                 else:
                     tcp_ctx.close()
         except socket.error as ex:
-            logger.warn(DDNS_RESPONSE_SOCKET_ERROR, ClientFormatter(dest), ex)
+            logger.warn(DDNS_RESPONSE_SOCKET_SEND_FAILED, ClientFormatter(dest), ex)
             return False
 
         return True
@@ -683,7 +683,7 @@ class DDNSServer:
                 result = ctx[0].send_ready()
                 if result != DNSTCPContext.SENDING:
                     if result == DNSTCPContext.CLOSED:
-                        logger.warn(DDNS_RESPONSE_TCP_SOCKET_ERROR,
+                        logger.warn(DDNS_RESPONSE_TCP_SOCKET_SEND_FAILED,
                                     ClientFormatter(ctx[1]))
                     ctx[0].close()
                     del self._tcp_ctxs[fileno]

src/bin/ddns/ddns_messages.mes

@@ -134,12 +134,12 @@ appropriate ACL configuration or some lower layer filtering.  The
 number of existing TCP clients are shown in the log, which should be
 identical to the current quota.
 
-% DDNS_RESPONSE_SOCKET_ERROR failed to send update response to %1: %2
+% DDNS_RESPONSE_SOCKET_SEND_FAILED failed to send update response to %1: %2
 Network I/O error happens in sending an update response.  The
 client's address that caused the error and error details are also
 logged.
 
-% DDNS_RESPONSE_TCP_SOCKET_ERROR failed to complete sending update response to %1 over TCP
+% DDNS_RESPONSE_TCP_SOCKET_SEND_FAILED failed to complete sending update response to %1 over TCP
 b10-ddns had tried to send an update response over TCP, and it hadn't
 been completed at that time, and a followup attempt to complete the
 send operation failed due to some network I/O error.  While a network

src/bin/resolver/resolver.cc

@@ -431,13 +431,14 @@ Resolver::processMessage(const IOMessage& io_message,
 
         // Ignore all responses.
         if (query_message->getHeaderFlag(Message::HEADERFLAG_QR)) {
-            LOG_DEBUG(resolver_logger, RESOLVER_DBG_IO, RESOLVER_UNEXPECTED_RESPONSE);
+            LOG_DEBUG(resolver_logger, RESOLVER_DBG_IO,
+                      RESOLVER_UNEXPECTED_RESPONSE);
             server->resume(false);
             return;
         }
     } catch (const Exception& ex) {
-        LOG_DEBUG(resolver_logger, RESOLVER_DBG_IO, RESOLVER_HEADER_ERROR)
-                  .arg(ex.what());
+        LOG_DEBUG(resolver_logger, RESOLVER_DBG_IO,
+                  RESOLVER_HEADER_PROCESSING_FAILED).arg(ex.what());
         server->resume(false);
         return;
     }
@@ -446,14 +447,16 @@ Resolver::processMessage(const IOMessage& io_message,
     try {
         query_message->fromWire(request_buffer);
     } catch (const DNSProtocolError& error) {
-        LOG_DEBUG(resolver_logger, RESOLVER_DBG_IO, RESOLVER_PROTOCOL_ERROR)
+        LOG_DEBUG(resolver_logger, RESOLVER_DBG_IO,
+                  RESOLVER_PROTOCOL_BODY_PARSE_FAILED)
                   .arg(error.what()).arg(error.getRcode());
         makeErrorMessage(query_message, answer_message,
                          buffer, error.getRcode());
         server->resume(true);
         return;
     } catch (const Exception& ex) {
-        LOG_DEBUG(resolver_logger, RESOLVER_DBG_IO, RESOLVER_MESSAGE_ERROR)
+        LOG_DEBUG(resolver_logger, RESOLVER_DBG_IO,
+                  RESOLVER_MESSAGE_PROCESSING_FAILED)
                   .arg(ex.what()).arg(Rcode::SERVFAIL());
         makeErrorMessage(query_message, answer_message,
                          buffer, Rcode::SERVFAIL());

src/bin/resolver/resolver_messages.mes

@@ -81,7 +81,7 @@ has passed a set of checks (message is well-formed, it is allowed by the
 ACL, it is a supported opcode, etc.) and is being forwarded to upstream
 servers.
 
-% RESOLVER_HEADER_ERROR message received, exception when processing header: %1
+% RESOLVER_HEADER_PROCESSING_FAILED message received, exception when processing header: %1
 This is a debug message from the resolver noting that an exception
 occurred during the processing of a received packet.  The packet has
 been dropped.
@@ -97,7 +97,7 @@ During the update of the resolver's configuration parameters, the value
 of the lookup timeout was found to be too small.  The configuration
 update will not be applied.
 
-% RESOLVER_MESSAGE_ERROR error parsing received message: %1 - returning %2
+% RESOLVER_MESSAGE_PROCESSING_FAILED error parsing received message: %1 - returning %2
 This is a debug message noting that parsing of the body of a received
 message by the resolver failed due to some error (although the parsing of
 the header succeeded).  The message parameters give a textual description
@@ -139,7 +139,7 @@ get them from a priming query.
 This debug message is logged when a "print_message" command is received
 by the resolver over the command channel.
 
-% RESOLVER_PROTOCOL_ERROR protocol error parsing received message: %1 - returning %2
+% RESOLVER_PROTOCOL_BODY_PARSE_FAILED protocol error parsing received message: %1 - returning %2
 This is a debug message noting that the resolver received a message and
 the parsing of the body of the message failed due to some protocol error
 (although the parsing of the header succeeded).  The message parameters

src/bin/xfrout/xfrout.py.in

@@ -756,7 +756,7 @@ class UnixSockServer(socketserver_mixin.NoPollMixIn,
         """
         sock_fd = recv_fd(request.fileno())
         if sock_fd < 0:
-            logger.warn(XFROUT_RECEIVE_FILE_DESCRIPTOR_ERROR)
+            logger.warn(XFROUT_RECEIVE_FD_FAILED)
             return False
 
         # receive request msg.  If it fails we simply terminate the thread;

src/bin/xfrout/xfrout_messages.mes

@@ -155,7 +155,7 @@ statistics data should be sent to the stats daemon.
 The xfrout daemon received a shutdown command from the command channel
 and will now shut down.
 
-% XFROUT_RECEIVE_FILE_DESCRIPTOR_ERROR error receiving the file descriptor for an XFR connection
+% XFROUT_RECEIVE_FD_FAILED error receiving the file descriptor for an XFR connection
 There was an error receiving the file descriptor for the transfer
 request from b10-auth.  There can be several reasons for this, but
 the most likely cause is that b10-auth terminates for some reason

src/lib/python/isc/ddns/libddns_messages.mes

@@ -121,7 +121,7 @@ a bad class. The class of the update RRset must be either the same
 as the class in the Zone Section, ANY, or NONE.
 A FORMERR response is sent back to the client.
 
-% LIBDDNS_UPDATE_DATASRC_ERROR error in datasource during DDNS update: %1
+% LIBDDNS_UPDATE_DATASRC_COMMIT_FAILED error in datasource during DDNS update: %1
 An error occurred while committing the DDNS update changes to the
 datasource. The specific error is printed. A SERVFAIL response is sent
 back to the client.
@@ -167,7 +167,7 @@ rejected by the zone's update ACL.  When this library is used by
 b10-ddns, the server will then completely ignore the request; no
 response will be sent.
 
-% LIBDDNS_UPDATE_ERROR update client %1 for zone %2: %3
+% LIBDDNS_UPDATE_PROCESSING_FAILED update client %1 for zone %2: %3
 Debug message.  An error is found in processing a dynamic update
 request.  This log message is used for general errors that are not
 normally expected to happen.  So, in general, it would mean some

src/lib/python/isc/ddns/session.py

@@ -259,7 +259,7 @@ class UpdateSession:
             return UPDATE_SUCCESS, self.__zname, self.__zclass
         except UpdateError as e:
             if not e.nolog:
-                logger.debug(logger.DBGLVL_TRACE_BASIC, LIBDDNS_UPDATE_ERROR,
+                logger.debug(logger.DBGLVL_TRACE_BASIC, LIBDDNS_UPDATE_PROCESSING_FAILED,
                              ClientFormatter(self.__client_addr, self.__tsig),
                              ZoneFormatter(e.zname, e.zclass), e)
             # If RCODE is specified, create a corresponding resonse and return
@@ -852,7 +852,7 @@ class UpdateSession:
             self.__diff.commit()
             return Rcode.NOERROR()
         except isc.datasrc.Error as dse:
-            logger.info(LIBDDNS_UPDATE_DATASRC_ERROR, dse)
+            logger.info(LIBDDNS_UPDATE_DATASRC_COMMIT_FAILED, dse)
             return Rcode.SERVFAIL()
         except Exception as uce:
             logger.error(LIBDDNS_UPDATE_UNCAUGHT_EXCEPTION,

src/lib/python/isc/server_common/dns_tcp.py

@@ -248,7 +248,7 @@ class DNSTCPContext:
                                  ClientFormatter(self.__remote_addr),
                                  self.__send_marker, total_len)
                     return self.SENDING
-                logger.warn(PYSERVER_COMMON_DNS_TCP_SEND_ERROR,
+                logger.warn(PYSERVER_COMMON_DNS_TCP_SEND_FAILED,
                             ClientFormatter(self.__remote_addr),
                             self.__send_marker, total_len, ex)
                 self.__sock.close()

src/lib/python/isc/server_common/server_common_messages.mes

@@ -27,7 +27,7 @@ transmitted over a TCP connection, possibly after multiple send
 operations.  The destination address and the total size of the message
 (including the 2-byte length field) are shown in the log message.
 
-% PYSERVER_COMMON_DNS_TCP_SEND_ERROR failed to send TCP message to %1 (%2/%3 bytes sent): %4
+% PYSERVER_COMMON_DNS_TCP_SEND_FAILED failed to send TCP message to %1 (%2/%3 bytes sent): %4
 A DNS message has been attempted to be sent out over a TCP connection,
 but it failed due to some network error.  Although it's not expected
 to happen too often, it can still happen for various reasons.  The

src/lib/resolve/recursive_query.cc

@@ -609,7 +609,7 @@ SERVFAIL:
         if (category == ResponseClassifier::RCODE) {
 
             // Special case as this message takes two arguments.
-            LOG_DEBUG(logger, RESLIB_DBG_RESULTS, RESLIB_RCODE_ERROR).
+            LOG_DEBUG(logger, RESLIB_DBG_RESULTS, RESLIB_RCODE_RETURNED).
                       arg(questionText(question_)).arg(rcode);
 
         } else {

src/lib/resolve/resolve_messages.mes

@@ -133,7 +133,7 @@ A debug message indicating that a protocol error was received and that
 the resolver is repeating the query to the same nameserver.  After this
 repeated query, there will be the indicated number of retries left.
 
-% RESLIB_RCODE_ERROR response to query for <%1> returns RCODE of %2
+% RESLIB_RCODE_RETURNED response to query for <%1> returns RCODE of %2
 A debug message, the response to the specified query indicated an error
 that is not covered by a specific code path.  A SERVFAIL will be returned.