kea/src/bin/msgq/msgq_messages.mes

# Copyright (C) 2012  Internet Systems Consortium, Inc. ("ISC")
#
# Permission to use, copy, modify, and/or distribute this software for any
# purpose with or without fee is hereby granted, provided that the above
# copyright notice and this permission notice appear in all copies.
#
# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
# AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
# PERFORMANCE OF THIS SOFTWARE.

# No namespace declaration - these constants go in the global namespace
# of the ddns messages python module.

# When you add a message to this file, it is a good idea to run
# <topsrcdir>/tools/reorder_message_file.py to make sure the
# messages are in the correct order.

% MSGQ_CFGMGR_SUBSCRIBED The config manager subscribed to message queue
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.

% MSGQ_COMMAND_UNKNOWN Unknown command '%1'
The message queue received a command from other module, but it doesn't
recognize it. This is probably either a coding error or inconsistency between
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_ERROR 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.
This may be caused by a programmer error (one of the components sending invalid
data) or possibly by incompatible version of msgq and the component (but that's
unlikely, as the protocol is not changed often).

% MSGQ_INVALID_CMD Received invalid command: %1
An unknown command listed in the log has been received. It is ignored. This
indicates either a programmer error (eg. a typo in the command name) or
incompatible version of a module and message queue daemon.

% MSGQ_LISTENER_FAILED Failed to initialize listener on socket file '%1': %2
The message queue daemon tried to listen on a file socket (the path is in the
message), but it failed. The error from the operating system is logged.

% MSGQ_LISTENER_SETUP Starting to listen on socket file '%1'
Debug message. The listener is trying to open a listening socket.

% MSGQ_LISTENER_STARTED Successfully started to listen
Debug message. The message queue successfully opened a listening socket and
waits for incoming connections.

% MSGQ_RECV_ERROR Error reading from socket %1: %2
There was a low-level error when reading from a socket. The error is logged and
the corresponding socket is dropped.  The errors include receiving
broken or (non empty but) incomplete data.  In either case it usually suggests
something unexpected happens within the BIND 10 system; it's probably
better to restart the system, and if it continues it should be
reported as a bug.  One known, probably non critical case is
the "connection reset by peer" (or its variants) socket error appearing
on shutdown.  It's known this happens when the remote client closes the
connection as part of shutdown process.  Such cases are normally expected
to be reported as receiving empty data (which we log it at the debug level
as the MSGQ_CLOSE_ON_RECV message), but for some (yet) unknown reason
it can also be reported as the system error.  At shutdown time it's expected
that connections are closed, so it's probably safe to ignore these messages
in such a case.  We still log them as an error as we've not figured out
how exactly that can happen.  In future, we may make the shutdown process
more robust so the msgq daemon can explicitly know when a client shuts down
more reliably.  If and when it's implemented this error message won't appear
on shutdown unless there's really something unexpected.

% MSGQ_RECV_HDR Received header: %1
Debug message. This message includes the whole routing header of a packet.

% MSGQ_SELECT_ERROR Error while waiting for events: %1
A low-level error happened when waiting for events, the error is logged. The
reason for this varies, but it usually means the system is short on some
resources.

% MSGQ_SEND_ERROR Error while sending to socket %1: %2
There was a low-level error when sending data to a socket. The error is logged
and the corresponding socket is dropped.

% MSGQ_SHUTDOWN Stopping Msgq
Debug message. The message queue is shutting down.

% MSGQ_SOCKET_REGISTERED Registered a socket descriptor %1 with lname %2
Debug message. The msgq daemon accepted a session request on the
shown descriptor of socket and assigned a unique identifier (lname)
for the client on that socket.

% MSGQ_SOCK_CLOSE Closing socket fd %1
Debug message. Closing the mentioned socket.

% MSGQ_START Msgq version %1 starting
Debug message. The message queue is starting up.

% MSGQ_START_FAIL Error during startup: %1
There was an error during early startup of the daemon. More concrete error is
in the log. The daemon terminates as a result.

% MSGQ_SUBS_APPEND_TARGET Appending to existing target for subscription to group '%1' for instance '%2'
Debug message. Creating a new subscription by appending it to already existing
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_SOCKET_TIMEOUT_ERROR Killing socket %1 because timeout exceeded (%2)
Outgoing data was queued up on a socket connected to msgq, but the other
side is not reading it. It could be deadlocked, or may not be monitoring
it. Both cases are programming errors and should be corrected. The socket
is closed on the msgq side.