kea/src/bin/bind10/bind10_messages.mes

# Copyright (C) 2011  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 xfrin messages python module.

% BIND10_CHECK_MSGQ_ALREADY_RUNNING checking if msgq is already running
The boss process is starting up and will now check if the message bus
daemon is already running. If so, it will not be able to start, as it
needs a dedicated message bus.

% BIND10_COMPONENT_FAILED component %1 (pid %2) failed: %3
The process terminated, but the bind10 boss didn't expect it to, which means
it must have failed.

% BIND10_COMPONENT_RESTART component %1 is about to restart
The named component failed previously and we will try to restart it to provide
as flawless service as possible, but it should be investigated what happened,
as it could happen again.

% BIND10_COMPONENT_START component %1 is starting
The named component is about to be started by the boss process.

% BIND10_COMPONENT_START_EXCEPTION component %1 failed to start: %2
An exception (mentioned in the message) happened during the startup of the
named component. The componet is not considered started and further actions
will be taken about it.

% BIND10_COMPONENT_STOP component %1 is being stopped
A component is about to be asked to stop willingly by the boss.

% BIND10_COMPONENT_UNSATISFIED component %1 is required to run and failed
A component failed for some reason (see previous messages). It is either a core
component or needed component that was just started. In any case, the system
can't continue without it and will terminate.

% BIND10_CONFIGURATOR_BUILD building plan '%1' -> '%2'
A debug message. This indicates that the configurator is building a plan
how to change configuration from the older one to newer one. This does no
real work yet, it just does the planning what needs to be done.

% BIND10_CONFIGURATOR_PLAN_INTERRUPTED configurator plan interrupted, only %1 of %2 done
There was an exception during some planned task. The plan will not continue and
only some tasks of the plan were completed. The rest is aborted. The exception
will be propagated.

% BIND10_CONFIGURATOR_RECONFIGURE reconfiguring running components
A different configuration of which components should be running is being
installed. All components that are no longer needed will be stopped and
newly introduced ones started. This happens at startup, when the configuration
is read the first time, or when an operator changes configuration of the boss.

% BIND10_CONFIGURATOR_RUN running plan of %1 tasks
A debug message. The configurator is about to execute a plan of actions it
computed previously.

% BIND10_CONFIGURATOR_START bind10 component configurator is starting up
The part that cares about starting and stopping the right component from the
boss process is starting up. This happens only once at the startup of the
boss process. It will start the basic set of processes now (the ones boss
needs to read the configuration), the rest will be started after the
configuration is known.

% BIND10_CONFIGURATOR_STOP bind10 component configurator is shutting down
The part that cares about starting and stopping processes in the boss is
shutting down. All started components will be shut down now (more precisely,
asked to terminate by their own, if they fail to comply, other parts of
the boss process will try to force them).

% BIND10_CONFIGURATOR_TASK performing task %1 on %2
A debug message. The configurator is about to perform one task of the plan it
is currently executing on the named component.

% BIND10_CONNECTING_TO_CC_FAIL failed to connect to configuration/command channel; try -v to see output from msgq
The boss process tried to connect to the communication channel for
commands and configuration updates during initialization, but it
failed.  This is a fatal startup error, and process will soon
terminate after some cleanup.  There can be several reasons for the
failure, but the most likely cause is that the msgq daemon failed to
start, and the most likely cause of the msgq failure is that it
doesn't have a permission to create a socket file for the
communication.  To confirm that, you can see debug messages from msgq
by starting BIND 10 with the -v command line option.  If it indicates
permission problem for msgq, make sure the directory where the socket
file is to be created is writable for the msgq process.  Note that if
you specify the -u option to change process users, the directory must
be writable for that user.

% BIND10_INVALID_STATISTICS_DATA invalid specification of statistics data specified
An error was encountered when the boss module specified
statistics data which is invalid for the boss specification file.

% BIND10_INVALID_USER invalid user: %1
The boss process was started with the -u option, to drop root privileges
and continue running as the specified user, but the user is unknown.

% BIND10_KILLING_ALL_PROCESSES killing all started processes
The boss module was not able to start every process it needed to start
during startup, and will now kill the processes that did get started.

% BIND10_LOST_SOCKET_CONSUMER consumer %1 of sockets disconnected, considering all its sockets closed
A connection from one of the applications which requested a socket was
closed. This means the application has terminated, so all the sockets it was
using are now closed and bind10 process can release them as well, unless the
same sockets are used by yet another application.

% BIND10_MSGQ_ALREADY_RUNNING msgq daemon already running, cannot start
There already appears to be a message bus daemon running. Either an
old process was not shut down correctly, and needs to be killed, or
another instance of BIND10, with the same msgq domain socket, is
running, which needs to be stopped.

% BIND10_MSGQ_DISAPPEARED msgq channel disappeared
While listening on the message bus channel for messages, it suddenly
disappeared. The msgq daemon may have died. This might lead to an
inconsistent state of the system, and BIND 10 will now shut down.

% BIND10_NO_SOCKET couldn't send a socket for token %1 because of error: %2
An error occurred when the bind10 process was asked to send a socket file
descriptor. The error is mentioned, most common reason is that the request
is invalid and may not come from bind10 process at all.

% BIND10_PROCESS_ENDED process %2 of %1 ended with status %3
This indicates a process started previously terminated. The process id
and component owning the process are indicated, as well as the exit code.
This doesn't distinguish if the process was supposed to terminate or not.

% BIND10_READING_BOSS_CONFIGURATION reading boss configuration
The boss process is starting up, and will now process the initial
configuration, as received from the configuration manager.

% BIND10_RECEIVED_COMMAND received command: %1
The boss module received a command and shall now process it. The command
is printed.

% BIND10_RECEIVED_NEW_CONFIGURATION received new configuration: %1
The boss module received a configuration update and is going to apply
it now. The new configuration is printed.

% BIND10_RECEIVED_SIGNAL received signal %1
The boss module received the given signal.

% BIND10_RESTART_COMPONENT_SKIPPED Skipped restarting a component %1
The boss module tried to restart a component after it failed (crashed)
unexpectedly, but the boss then found that the component had been removed
from its local configuration of components to run.  This is an unusal
situation but can happen if the administrator removes the component from
the configuration after the component's crash and before the restart time.
The boss module simply skipped restarting that module, and the whole system
went back to the expected state (except that the crash itself is likely
to be a bug).

% BIND10_RESURRECTED_PROCESS resurrected %1 (PID %2)
The given process has been restarted successfully, and is now running
with the given process id.

% BIND10_RESURRECTING_PROCESS resurrecting dead %1 process...
The given process has ended unexpectedly, and is now restarted.

% BIND10_SELECT_ERROR error in select() call: %1
There was a fatal error in the call to select(), used to see if a child
process has ended or if there is a message on the message bus. This
should not happen under normal circumstances and is considered fatal,
so BIND 10 will now shut down. The specific error is printed.

% BIND10_SEND_SIGKILL sending SIGKILL to %1 (PID %2)
The boss module is sending a SIGKILL signal to the given process.

% BIND10_SEND_SIGNAL_FAIL sending %1 to %2 (PID %3) failed: %4
The boss module sent a single (either SIGTERM or SIGKILL) to a process,
but it failed due to some system level error.  There are two major cases:
the target process has already terminated but the boss module had sent
the signal before it noticed the termination.  In this case an error
message should indicate something like "no such process".  This can be
safely ignored.  The other case is that the boss module doesn't have
the privilege to send a signal to the process.  It can typically
happen when the boss module started as a privileged process, spawned a
subprocess, and then dropped the privilege.  It includes the case for
the socket creator when the boss process runs with the -u command line
option.  In this case, the boss module simply gives up to terminate
the process explicitly because it's unlikely to succeed by keeping
sending the signal.  Although the socket creator is implemented so
that it will terminate automatically when the boss process exits
(and that should be the case for any other future process running with
a higher privilege), but it's recommended to check if there's any
remaining BIND 10 process if this message is logged.  For all other
cases, the boss module will keep sending the signal until it confirms
all child processes terminate.  Although unlikely, this could prevent
the boss module from exiting, just keeping sending the signals.  So,
again, it's advisable to check if it really terminates when this
message is logged.

% BIND10_SEND_SIGTERM sending SIGTERM to %1 (PID %2)
The boss module is sending a SIGTERM signal to the given process.

% BIND10_SETGID setting GID to %1
The boss switches the process group ID to the given value.  This happens
when BIND 10 starts with the -u option, and the group ID will be set to
that of the specified user.

% BIND10_SETUID setting UID to %1
The boss switches the user it runs as to the given UID.

% BIND10_SHUTDOWN stopping the server
The boss process received a command or signal telling it to shut down.
It will send a shutdown command to each process. The processes that do
not shut down will then receive a SIGTERM signal. If that doesn't work,
it shall send SIGKILL signals to the processes still alive.

% BIND10_SHUTDOWN_COMPLETE all processes ended, shutdown complete
All child processes have been stopped, and the boss process will now
stop itself.

% BIND10_SOCKCREATOR_BAD_CAUSE unknown error cause from socket creator: %1
The socket creator reported an error when creating a socket. But the function
which failed is unknown (not one of 'S' for socket or 'B' for bind).

% BIND10_SOCKCREATOR_BAD_RESPONSE unknown response for socket request: %1
The boss requested a socket from the creator, but the answer is unknown. This
looks like a programmer error.

% BIND10_SOCKCREATOR_EOF eof while expecting data from socket creator
There should be more data from the socket creator, but it closed the socket.
It probably crashed.

% BIND10_SOCKCREATOR_INIT initializing socket creator parser
The boss module initializes routines for parsing the socket creator
protocol.

% BIND10_SOCKCREATOR_KILL killing the socket creator
The socket creator is being terminated the aggressive way, by sending it
sigkill. This should not happen usually.

% BIND10_SOCKCREATOR_TERMINATE terminating socket creator
The boss module sends a request to terminate to the socket creator.

% BIND10_SOCKCREATOR_TRANSPORT_ERROR transport error when talking to the socket creator: %1
Either sending or receiving data from the socket creator failed with the given
error. The creator probably crashed or some serious OS-level problem happened,
as the communication happens only on local host.

% BIND10_SOCKET_CREATED successfully created socket %1
The socket creator successfully created and sent a requested socket, it has
the given file number.

% BIND10_SOCKET_ERROR error on %1 call in the creator: %2/%3
The socket creator failed to create the requested socket. It failed on the
indicated OS API function with given error.

% BIND10_SOCKET_GET requesting socket [%1]:%2 of type %3 from the creator
The boss forwards a request for a socket to the socket creator.

% BIND10_STARTED_CC started configuration/command session
Debug message given when BIND 10 has successfull started the object that
handles configuration and commands.

% BIND10_STARTED_PROCESS started %1
The given process has successfully been started.

% BIND10_STARTED_PROCESS_PID started %1 (PID %2)
The given process has successfully been started, and has the given PID.

% BIND10_STARTING starting BIND10: %1
Informational message on startup that shows the full version.

% BIND10_STARTING_CC starting configuration/command session
Informational message given when BIND 10 is starting the session object
that handles configuration and commands.

% BIND10_STARTING_PROCESS starting process %1
The boss module is starting the given process.

% BIND10_STARTING_PROCESS_PORT starting process %1 (to listen on port %2)
The boss module is starting the given process, which will listen on the
given port number.

% BIND10_STARTING_PROCESS_PORT_ADDRESS starting process %1 (to listen on %2#%3)
The boss module is starting the given process, which will listen on the
given address and port number (written as <address>#<port>).

% BIND10_STARTUP_COMPLETE BIND 10 started
All modules have been successfully started, and BIND 10 is now running.

% BIND10_STARTUP_ERROR error during startup: %1
There was a fatal error when BIND10 was trying to start. The error is
shown, and BIND10 will now shut down.

% BIND10_STARTUP_UNEXPECTED_MESSAGE unrecognised startup message %1
During the startup process, a number of messages are exchanged between the
Boss process and the processes it starts.  This error is output when a
message received by the Boss process is recognised as being of the
correct format but is unexpected.  It may be that processes are starting
of sequence.

% BIND10_STARTUP_UNRECOGNISED_MESSAGE unrecognised startup message %1
During the startup process, a number of messages are exchanged between the
Boss process and the processes it starts.  This error is output when a
message received by the Boss process is not recognised.

% BIND10_START_AS_NON_ROOT_RESOLVER starting b10-resolver as a user, not root. This might fail.
The resolver is being started or restarted without root privileges.
If the module needs these privileges, it may have problems starting.
Note that this issue should be resolved by the pending 'socket-creator'
process; once that has been implemented, modules should not need root
privileges anymore. See tickets #800 and #801 for more information.

% BIND10_STOP_PROCESS asking %1 to shut down
The boss module is sending a shutdown command to the given module over
the message channel.

% BIND10_UNKNOWN_CHILD_PROCESS_ENDED unknown child pid %1 exited
An unknown child process has exited. The PID is printed, but no further
action will be taken by the boss process.

% BIND10_WAIT_CFGMGR waiting for configuration manager process to initialize
The configuration manager process is so critical to operation of BIND 10
that after starting it, the Boss module will wait for it to initialize
itself before continuing.  This debug message is produced during the
wait and may be output zero or more times depending on how long it takes
the configuration manager to start up.  The total length of time Boss
will wait for the configuration manager before reporting an error is
set with the command line --wait switch, which has a default value of
ten seconds.