[2003] sorted log messages.

src/bin/ddns/ddns_messages.mes

@@ -81,11 +81,38 @@ this stage and should rather be considered an internal bug.  This
 event is therefore logged at the error level, and the request is
 simply dropped.  Additional information of the error is also logged.
 
+% DDNS_REQUEST_TCP_QUOTA reject TCP update client %1 (%2 running)
+b10-ddns received a new update request from a client over TCP, but
+the number of TCP clients being handled by the server already reached
+the configured quota, so the latest client was rejected by closing
+the connection.  The administrator may want to check the status of
+b10-ddns, and if this happens even if the server is not very busy,
+the quota may have to be increased.  Or, if it's more likely to be
+malicious or simply bogus clients that somehow keep the TCP connection
+open for a long period, maybe they should be rejected with an
+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
 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
+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
+error can happen any time, this event is quite unexpected for two
+reasons.  First, since the size of a response to an update request
+should be generally small, it's unlikely that the initial attempt
+didn't fail but wasn't completed.  Second, since the first attempt
+succeeded and the TCP connection had been established in the first
+place, it's more likely for the subsequent attempt to succeed.  In any
+case, there may not be able to do anything to fix it at the server
+side, but the administrator may want to check the general reachability
+with the client address.
+
 % DDNS_RUNNING ddns server is running and listening for updates
 The ddns process has successfully started and is now ready to receive commands
 and updates.
@@ -135,30 +162,3 @@ needs to examine this message and takes an appropriate action.  In
 either case, this notification is generally expected to succeed; so
 the fact it fails itself means there's something wrong in the BIND 10
 system, and it would be advisable to check other log messages.
-
-% DDNS_RESPONSE_TCP_SOCKET_ERROR 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
-error can happen any time, this event is quite unexpected for two
-reasons.  First, since the size of a response to an update request
-should be generally small, it's unlikely that the initial attempt
-didn't fail but wasn't completed.  Second, since the first attempt
-succeeded and the TCP connection had been established in the first
-place, it's more likely for the subsequent attempt to succeed.  In any
-case, there may not be able to do anything to fix it at the server
-side, but the administrator may want to check the general reachability
-with the client address.
-
-% DDNS_REQUEST_TCP_QUOTA reject TCP update client %1 (%2 running)
-b10-ddns received a new update request from a client over TCP, but
-the number of TCP clients being handled by the server already reached
-the configured quota, so the latest client was rejected by closing
-the connection.  The administrator may want to check the status of
-b10-ddns, and if this happens even if the server is not very busy,
-the quota may have to be increased.  Or, if it's more likely to be
-malicious or simply bogus clients that somehow keep the TCP connection
-open for a long period, maybe they should be rejected with an
-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.

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

@@ -21,33 +21,12 @@
 # have that at this moment. So when adding a message, make sure that
 # the name is not already used in src/lib/config/config_messages.mes
 
-% PYSERVER_COMMON_TSIG_KEYRING_DEINIT Deinitializing global TSIG keyring
-A debug message noting that the global TSIG keyring is being removed from
-memory. Most programs don't do that, they just exit, which is OK.
-
-% PYSERVER_COMMON_TSIG_KEYRING_INIT Initializing global TSIG keyring
-A debug message noting the TSIG keyring storage is being prepared. It should
-appear at most once in the lifetime of a program. The keyring still needs
-to be loaded from configuration.
-
-% PYSERVER_COMMON_TSIG_KEYRING_UPDATE Updating global TSIG keyring
-A debug message. The TSIG keyring is being (re)loaded from configuration.
-This happens at startup or when the configuration changes. The old keyring
-is removed and new one created with all the keys.
-
 % PYSERVER_COMMON_DNS_TCP_SEND_DONE completed sending TCP message to %1 (%2 bytes in total)
 Debug message.  A complete DNS message has been successfully
 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_PENDING sent part TCP message to %1 (up to %2 bytes)
-Debug message.  A part of DNS message has been transmitted over a TCP
-connection, and it's suspended because further attempt would block.
-The destination address and the total size of the message that has
-been transmitted so far (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 bytes sent): %3
 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
@@ -57,3 +36,24 @@ included in the log message, to see if it requires some action to
 be taken at the server side.  When this message is logged, the
 corresponding  TCP connection was closed immediately after the error
 was detected.
+
+% PYSERVER_COMMON_DNS_TCP_SEND_PENDING sent part TCP message to %1 (up to %2 bytes)
+Debug message.  A part of DNS message has been transmitted over a TCP
+connection, and it's suspended because further attempt would block.
+The destination address and the total size of the message that has
+been transmitted so far (including the 2-byte length field) are shown
+in the log message.
+
+% PYSERVER_COMMON_TSIG_KEYRING_DEINIT Deinitializing global TSIG keyring
+A debug message noting that the global TSIG keyring is being removed from
+memory. Most programs don't do that, they just exit, which is OK.
+
+% PYSERVER_COMMON_TSIG_KEYRING_INIT Initializing global TSIG keyring
+A debug message noting the TSIG keyring storage is being prepared. It should
+appear at most once in the lifetime of a program. The keyring still needs
+to be loaded from configuration.
+
+% PYSERVER_COMMON_TSIG_KEYRING_UPDATE Updating global TSIG keyring
+A debug message. The TSIG keyring is being (re)loaded from configuration.
+This happens at startup or when the configuration changes. The old keyring
+is removed and new one created with all the keys.