# 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 # /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.