|
|
@@ -131,6 +131,19 @@ discovered that the memory data source is disabled for the given class.
|
|
|
</p></dd><dt><a name="AUTH_MEM_DATASRC_ENABLED"></a><span class="term">AUTH_MEM_DATASRC_ENABLED memory data source is enabled for class %1</span></dt><dd><p>
|
|
|
This is a debug message reporting that the authoritative server has
|
|
|
discovered that the memory data source is enabled for the given class.
|
|
|
+</p></dd><dt><a name="AUTH_MESSAGE_FORWARD_ERROR"></a><span class="term">AUTH_MESSAGE_FORWARD_ERROR failed to forward %1 request from %2: %3</span></dt><dd><p>
|
|
|
+The authoritative server tried to forward some type DNS request
|
|
|
+message to a separate process (e.g., forwarding dynamic update
|
|
|
+requests to b10-ddns) to handle it, but it failed. The authoritative
|
|
|
+server returns SERVFAIL to the client on behalf of the separate
|
|
|
+process. The error could be configuration mismatch between b10-auth
|
|
|
+and the recipient component, or it may be because the requests are
|
|
|
+coming too fast and the receipient process cannot keep up with the
|
|
|
+rate, or some system level failure. In either case this means the
|
|
|
+BIND 10 system is not working as expected, so the administrator should
|
|
|
+look into the cause and address the issue. The log message includes
|
|
|
+the client's address (and port), and the error message sent from the
|
|
|
+lower layer that detects the failure.
|
|
|
</p></dd><dt><a name="AUTH_NOTIFY_QUESTIONS"></a><span class="term">AUTH_NOTIFY_QUESTIONS invalid number of questions (%1) in incoming NOTIFY</span></dt><dd><p>
|
|
|
This debug message is logged by the authoritative server when it receives
|
|
|
a NOTIFY packet that contains zero or more than one question. (A valid
|
|
|
@@ -395,6 +408,10 @@ so BIND 10 will now shut down. The specific error is printed.
|
|
|
The boss module is sending a SIGKILL signal to the given process.
|
|
|
</p></dd><dt><a name="BIND10_SEND_SIGTERM"></a><span class="term">BIND10_SEND_SIGTERM sending SIGTERM to %1 (PID %2)</span></dt><dd><p>
|
|
|
The boss module is sending a SIGTERM signal to the given process.
|
|
|
+</p></dd><dt><a name="BIND10_SETGID"></a><span class="term">BIND10_SETGID setting GID to %1</span></dt><dd><p>
|
|
|
+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.
|
|
|
</p></dd><dt><a name="BIND10_SETUID"></a><span class="term">BIND10_SETUID setting UID to %1</span></dt><dd><p>
|
|
|
The boss switches the user it runs as to the given UID.
|
|
|
</p></dd><dt><a name="BIND10_SHUTDOWN"></a><span class="term">BIND10_SHUTDOWN stopping the server</span></dt><dd><p>
|
|
|
@@ -671,6 +688,11 @@ all messages must contain at least the envelope.
|
|
|
An older version of the configuration database has been found, from which
|
|
|
there was an automatic upgrade path to the current version. These changes
|
|
|
are now applied, and no action from the administrator is necessary.
|
|
|
+</p></dd><dt><a name="CFGMGR_BACKED_UP_CONFIG_FILE"></a><span class="term">CFGMGR_BACKED_UP_CONFIG_FILE Config file %1 was removed; a backup was made at %2</span></dt><dd><p>
|
|
|
+BIND 10 has been started with the command to clear the configuration
|
|
|
+file. The existing file has been backed up (moved) to the given file
|
|
|
+name. A new configuration file will be created in the original location
|
|
|
+when necessary.
|
|
|
</p></dd><dt><a name="CFGMGR_BAD_UPDATE_RESPONSE_FROM_MODULE"></a><span class="term">CFGMGR_BAD_UPDATE_RESPONSE_FROM_MODULE Unable to parse response from module %1: %2</span></dt><dd><p>
|
|
|
The configuration manager sent a configuration update to a module, but
|
|
|
the module responded with an answer that could not be parsed. The answer
|
|
|
@@ -700,10 +722,6 @@ was trying to write the configuration database to disk. The specific
|
|
|
error is given. The most likely cause is that the system does not have
|
|
|
write access to the configuration database file. The updated
|
|
|
configuration is not stored.
|
|
|
-</p></dd><dt><a name="CFGMGR_RENAMED_CONFIG_FILE"></a><span class="term">CFGMGR_RENAMED_CONFIG_FILE renamed configuration file %1 to %2, will create new %1</span></dt><dd><p>
|
|
|
-BIND 10 has been started with the command to clear the configuration file.
|
|
|
-The existing file is backed up to the given file name, so that data is not
|
|
|
-immediately lost if this was done by accident.
|
|
|
</p></dd><dt><a name="CFGMGR_STOPPED_BY_KEYBOARD"></a><span class="term">CFGMGR_STOPPED_BY_KEYBOARD keyboard interrupt, shutting down</span></dt><dd><p>
|
|
|
There was a keyboard interrupt signal to stop the cfgmgr daemon. The
|
|
|
daemon will now shut down.
|
|
|
@@ -891,9 +909,12 @@ in the answer as a result.
|
|
|
</p></dd><dt><a name="DATASRC_DATABASE_FINDNSEC3"></a><span class="term">DATASRC_DATABASE_FINDNSEC3 Looking for NSEC3 for %1 in %2 mode</span></dt><dd><p>
|
|
|
Debug information. A search in an database data source for NSEC3 that
|
|
|
matches or covers the given name is being started.
|
|
|
-</p></dd><dt><a name="DATASRC_DATABASE_FINDNSEC3_COVER"></a><span class="term">DATASRC_DATABASE_FINDNSEC3_COVER found a covering NSEC3 for %1: %2</span></dt><dd><p>
|
|
|
+</p></dd><dt><a name="DATASRC_DATABASE_FINDNSEC3_COVER"></a><span class="term">DATASRC_DATABASE_FINDNSEC3_COVER found a covering NSEC3 for %1 at label count %2: %3</span></dt><dd><p>
|
|
|
Debug information. An NSEC3 that covers the given name is found and
|
|
|
-being returned. The found NSEC3 RRset is also displayed.
|
|
|
+being returned. The found NSEC3 RRset is also displayed. When the shown label
|
|
|
+count is smaller than that of the given name, the matching NSEC3 is for a
|
|
|
+superdomain of the given name (see DATASRC_DATABSE_FINDNSEC3_TRYHASH). The
|
|
|
+found NSEC3 RRset is also displayed.
|
|
|
</p></dd><dt><a name="DATASRC_DATABASE_FINDNSEC3_MATCH"></a><span class="term">DATASRC_DATABASE_FINDNSEC3_MATCH found a matching NSEC3 for %1 at label count %2: %3</span></dt><dd><p>
|
|
|
Debug information. An NSEC3 that matches (a possibly superdomain of)
|
|
|
the given name is found and being returned. When the shown label
|
|
|
@@ -954,7 +975,7 @@ name and class, but not for the given type.
|
|
|
A search in the database for RRs for the specified name, type and class has
|
|
|
located RRs that match the name and class but not the type. DNSSEC information
|
|
|
has been requested and returned.
|
|
|
-</p></dd><dt><a name="DATASRC_DATABASE_FOUND_RRSET"></a><span class="term">DATASRC_DATABASE_FOUND_RRSET search in datasource %1 resulted in RRset %5</span></dt><dd><p>
|
|
|
+</p></dd><dt><a name="DATASRC_DATABASE_FOUND_RRSET"></a><span class="term">DATASRC_DATABASE_FOUND_RRSET search in datasource %1 resulted in RRset %2</span></dt><dd><p>
|
|
|
The data returned by the database backend contained data for the given domain
|
|
|
name, and it either matches the type or has a relevant type. The RRset that is
|
|
|
returned is printed.
|
|
|
@@ -1053,7 +1074,7 @@ The given wildcard matches the name being sough but it as an empty
|
|
|
nonterminal (e.g. there's nothing at *.example.com but something like
|
|
|
subdomain.*.example.org, do exist: so *.example.org exists in the
|
|
|
namespace but has no RRs assopciated with it). This will produce NXRRSET.
|
|
|
-</p></dd><dt><a name="DATASRC_DATABASE_WILDCARD_MATCH"></a><span class="term">DATASRC_DATABASE_WILDCARD_MATCH search in datasource %1 resulted in wildcard match at %5 with RRset %6</span></dt><dd><p>
|
|
|
+</p></dd><dt><a name="DATASRC_DATABASE_WILDCARD_MATCH"></a><span class="term">DATASRC_DATABASE_WILDCARD_MATCH search in datasource %1 resulted in wildcard match at %2 with RRset %3</span></dt><dd><p>
|
|
|
The database doesn't contain directly matching name. When searching
|
|
|
for a wildcard match, a wildcard record matching the name and type of
|
|
|
the query was found. The data at this point is returned.
|
|
|
@@ -1526,6 +1547,11 @@ There was a low-level error when we tried to accept an incoming connection
|
|
|
(probably coming from b10-auth). We continue serving on whatever other
|
|
|
connections we already have, but this connection is dropped. The reason
|
|
|
is logged.
|
|
|
+</p></dd><dt><a name="DDNS_AUTH_DBFILE_UPDATE"></a><span class="term">DDNS_AUTH_DBFILE_UPDATE updated auth DB file to %1</span></dt><dd><p>
|
|
|
+b10-ddns was notified of updates to the SQLite3 DB file that b10-auth
|
|
|
+uses for the underlying data source and on which b10-ddns needs to
|
|
|
+make updates. b10-ddns then updated its internal setup so further
|
|
|
+updates would be made on the new DB.
|
|
|
</p></dd><dt><a name="DDNS_CC_SESSION_ERROR"></a><span class="term">DDNS_CC_SESSION_ERROR error reading from cc channel: %1</span></dt><dd><p>
|
|
|
There was a problem reading from the command and control channel. The
|
|
|
most likely cause is that the msgq process is not running.
|
|
|
@@ -1536,12 +1562,41 @@ configuration manager b10-cfgmgr is not running.
|
|
|
</p></dd><dt><a name="DDNS_CONFIG_ERROR"></a><span class="term">DDNS_CONFIG_ERROR error found in configuration data: %1</span></dt><dd><p>
|
|
|
The ddns process encountered an error when installing the configuration at
|
|
|
startup time. Details of the error are included in the log message.
|
|
|
+</p></dd><dt><a name="DDNS_CONFIG_HANDLER_ERROR"></a><span class="term">DDNS_CONFIG_HANDLER_ERROR failed to update ddns configuration: %1</span></dt><dd><p>
|
|
|
+An update to b10-ddns configuration was delivered but an error was
|
|
|
+found while applying them. None of the delivered updates were applied
|
|
|
+to the running b10-ddns system, and the server will keep running with
|
|
|
+the existing configuration. If this happened in the initial
|
|
|
+configuration setup, the server will be running with the default
|
|
|
+configurations.
|
|
|
</p></dd><dt><a name="DDNS_DROP_CONN"></a><span class="term">DDNS_DROP_CONN dropping connection on file descriptor %1 because of error %2</span></dt><dd><p>
|
|
|
There was an error on a connection with the b10-auth server (or whatever
|
|
|
connects to the ddns daemon). This might be OK, for example when the
|
|
|
authoritative server shuts down, the connection would get closed. It also
|
|
|
can mean the system is busy and can't keep up or that the other side got
|
|
|
confused and sent bad data.
|
|
|
+</p></dd><dt><a name="DDNS_GET_REMOTE_CONFIG_FAIL"></a><span class="term">DDNS_GET_REMOTE_CONFIG_FAIL failed to get %1 module configuration %2 times: %3</span></dt><dd><p>
|
|
|
+b10-ddns tried to get configuration of some remote modules for its
|
|
|
+operation, but it failed. The most likely cause of this is that the
|
|
|
+remote module has not fully started up and b10-ddns couldn't get the
|
|
|
+configuration in a timely fashion. b10-ddns attempts to retry it a
|
|
|
+few times, imposing a short delay, hoping it eventually succeeds if
|
|
|
+it's just a timing issue. The number of total failed attempts is also
|
|
|
+logged. If it reaches an internal threshold b10-ddns considers it a
|
|
|
+fatal error and terminates. Even in that case, if b10-ddns is
|
|
|
+configured as a "dispensable" component (which is the default), the
|
|
|
+parent bind10 process will restart it, and there will be another
|
|
|
+chance of getting the remote configuration successfully. These are
|
|
|
+not the optimal behavior, but it's believed to be sufficient in
|
|
|
+practice (there would normally be no failure in the first place). If
|
|
|
+it really causes an operational trouble other than having a few of
|
|
|
+these log messages, please submit a bug report; there can be several
|
|
|
+ways to make it more sophisticated. Another, less likely reason for
|
|
|
+having this error is because the remote modules are not actually
|
|
|
+configured to run. If that's the case fixing the configuration should
|
|
|
+solve the problem - either by making sure the remote module will run
|
|
|
+or by not running b10-ddns (without these remote modules b10-ddns is
|
|
|
+not functional, so there's no point in running it in this case).
|
|
|
</p></dd><dt><a name="DDNS_MODULECC_SESSION_ERROR"></a><span class="term">DDNS_MODULECC_SESSION_ERROR error encountered by configuration/command module: %1</span></dt><dd><p>
|
|
|
There was a problem in the lower level module handling configuration and
|
|
|
control commands. This could happen for various reasons, but the most likely
|
|
|
@@ -1553,12 +1608,80 @@ Debug message. We received a connection and we are going to start handling
|
|
|
requests from it. The file descriptor number and the address where the request
|
|
|
comes from is logged. The connection is over a unix domain socket and is likely
|
|
|
coming from a b10-auth process.
|
|
|
+</p></dd><dt><a name="DDNS_RECEIVED_AUTH_UPDATE"></a><span class="term">DDNS_RECEIVED_AUTH_UPDATE received configuration updates from auth server</span></dt><dd><p>
|
|
|
+b10-ddns is notified of updates to b10-auth configuration
|
|
|
+(including a report of the initial configuration) that b10-ddns might
|
|
|
+be interested in.
|
|
|
</p></dd><dt><a name="DDNS_RECEIVED_SHUTDOWN_COMMAND"></a><span class="term">DDNS_RECEIVED_SHUTDOWN_COMMAND shutdown command received</span></dt><dd><p>
|
|
|
The ddns process received a shutdown command from the command channel
|
|
|
and will now shut down.
|
|
|
-</p></dd><dt><a name="DDNS_RUNNING"></a><span class="term">DDNS_RUNNING ddns server is running and listening for updates</span></dt><dd><p>
|
|
|
-The ddns process has successfully started and is now ready to receive commands
|
|
|
-and updates.
|
|
|
+</p></dd><dt><a name="DDNS_RECEIVED_ZONEMGR_UPDATE"></a><span class="term">DDNS_RECEIVED_ZONEMGR_UPDATE received configuration updates from zonemgr</span></dt><dd><p>
|
|
|
+b10-ddns is notified of updates to b10-zonemgr's configuration
|
|
|
+(including a report of the initial configuration). It may possibly
|
|
|
+contain changes to the secondary zones, in which case b10-ddns will
|
|
|
+update its internal copy of that configuration.
|
|
|
+</p></dd><dt><a name="DDNS_REQUEST_PARSE_FAIL"></a><span class="term">DDNS_REQUEST_PARSE_FAIL failed to parse update request: %1</span></dt><dd><p>
|
|
|
+b10-ddns received an update request via b10-auth, but the received
|
|
|
+data failed to pass minimum validation: it was either broken wire
|
|
|
+format data for a valid DNS message (e.g. it's shorter than the
|
|
|
+fixed-length header), or the opcode is not update, or TSIG is included
|
|
|
+in the request but it fails to validate. Since b10-auth should have
|
|
|
+performed this level of checks, such an error shouldn't be detected at
|
|
|
+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.
|
|
|
+</p></dd><dt><a name="DDNS_REQUEST_TCP_QUOTA"></a><span class="term">DDNS_REQUEST_TCP_QUOTA reject TCP update client %1 (%2 running)</span></dt><dd><p>
|
|
|
+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.
|
|
|
+</p></dd><dt><a name="DDNS_RESPONSE_SOCKET_ERROR"></a><span class="term">DDNS_RESPONSE_SOCKET_ERROR failed to send update response to %1: %2</span></dt><dd><p>
|
|
|
+Network I/O error happens in sending an update response. The
|
|
|
+client's address that caused the error and error details are also
|
|
|
+logged.
|
|
|
+</p></dd><dt><a name="DDNS_RESPONSE_TCP_SOCKET_ERROR"></a><span class="term">DDNS_RESPONSE_TCP_SOCKET_ERROR failed to complete sending update response to %1 over TCP</span></dt><dd><p>
|
|
|
+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.
|
|
|
+</p></dd><dt><a name="DDNS_SECONDARY_ZONES_UPDATE"></a><span class="term">DDNS_SECONDARY_ZONES_UPDATE updated secondary zone list (%1 zones are listed)</span></dt><dd><p>
|
|
|
+b10-ddns has successfully updated the internal copy of secondary zones
|
|
|
+obtained from b10-zonemgr, based on a latest update to zonemgr's
|
|
|
+configuration. The number of newly configured (unique) secondary
|
|
|
+zones is logged.
|
|
|
+</p></dd><dt><a name="DDNS_SECONDARY_ZONES_UPDATE_FAIL"></a><span class="term">DDNS_SECONDARY_ZONES_UPDATE_FAIL failed to update secondary zone list: %1</span></dt><dd><p>
|
|
|
+An error message. b10-ddns was notified of updates to a list of
|
|
|
+secondary zones from b10-zonemgr and tried to update its own internal
|
|
|
+copy of the list, but it failed. This can happen if the configuration
|
|
|
+contains an error, and b10-zonemgr should also reject that update.
|
|
|
+Unfortunately, in the current implementation there is no way to ensure
|
|
|
+that both zonemgr and ddns have consistent information when an update
|
|
|
+contains an error; further, as of this writing zonemgr has a bug that
|
|
|
+it could partially update the list of secondary zones if part of the
|
|
|
+list has an error (see Trac ticket #2038). b10-ddns still keeps
|
|
|
+running with the previous configuration, but it's strongly advisable
|
|
|
+to check log messages from zonemgr, and if it indicates there can be
|
|
|
+inconsistent state, it's better to restart the entire BIND 10 system
|
|
|
+(just restarting b10-ddns wouldn't be enough, because zonemgr can have
|
|
|
+partially updated configuration due to bug #2038). The log message
|
|
|
+contains an error description, but it's intentionally kept simple as
|
|
|
+it's primarily a matter of zonemgr. To know the details of the error,
|
|
|
+log messages of zonemgr should be consulted.
|
|
|
</p></dd><dt><a name="DDNS_SESSION"></a><span class="term">DDNS_SESSION session arrived on file descriptor %1</span></dt><dd><p>
|
|
|
A debug message, informing there's some activity on the given file descriptor.
|
|
|
It will be either a request or the file descriptor will be closed. See
|
|
|
@@ -1567,6 +1690,9 @@ following log messages to see what of it.
|
|
|
The ddns process is shutting down. It will no longer listen for new commands
|
|
|
or updates. Any command or update that is being addressed at this moment will
|
|
|
be completed, after which the process will exit.
|
|
|
+</p></dd><dt><a name="DDNS_STARTED"></a><span class="term">DDNS_STARTED ddns server is running and listening for updates</span></dt><dd><p>
|
|
|
+The ddns process has successfully started and is now ready to receive commands
|
|
|
+and updates.
|
|
|
</p></dd><dt><a name="DDNS_STOPPED"></a><span class="term">DDNS_STOPPED ddns server has stopped</span></dt><dd><p>
|
|
|
The ddns process has successfully stopped and is no longer listening for or
|
|
|
handling commands or updates, and will now exit.
|
|
|
@@ -1577,6 +1703,212 @@ process will now shut down.
|
|
|
The b10-ddns process encountered an uncaught exception and will now shut
|
|
|
down. This is indicative of a programming error and should not happen under
|
|
|
normal circumstances. The exception type and message are printed.
|
|
|
+</p></dd><dt><a name="DDNS_UPDATE_NOTIFY"></a><span class="term">DDNS_UPDATE_NOTIFY notified %1 of updates to %2</span></dt><dd><p>
|
|
|
+Debug message. b10-ddns has made updates to a zone based on an update
|
|
|
+request and has successfully notified an external module of the updates.
|
|
|
+The notified module will use that information for updating its own
|
|
|
+state or any necessary protocol action such as zone reloading or sending
|
|
|
+notify messages to secondary servers.
|
|
|
+</p></dd><dt><a name="DDNS_UPDATE_NOTIFY_FAIL"></a><span class="term">DDNS_UPDATE_NOTIFY_FAIL failed to notify %1 of updates to %2: %3</span></dt><dd><p>
|
|
|
+b10-ddns has made updates to a zone based on an update request and
|
|
|
+tried to notify an external component of the updates, but the
|
|
|
+notification fails. One possible cause of this is that the external
|
|
|
+component is not really running and it times out in waiting for the
|
|
|
+response, although it will be less likely to happen in practice
|
|
|
+because these components will normally be configured to run when the
|
|
|
+server provides the authoritative DNS service; ddns is rather optional
|
|
|
+among them. If this happens, however, it will suspend b10-ddns for a
|
|
|
+few seconds during which it cannot handle new requests (some may be
|
|
|
+delayed, some may be dropped, depending on the volume of the incoming
|
|
|
+requests). This is obviously bad, and if this error happens due to
|
|
|
+this reason, the administrator should make sure the component in
|
|
|
+question should be configured to run. For a longer term, b10-ddns
|
|
|
+should be more robust about this case such as by making this
|
|
|
+notification asynchronously and/or detecting the existence of the
|
|
|
+external components to avoid hopeless notification in the first place.
|
|
|
+Severity of this error for the receiving components depends on the
|
|
|
+type of the component. If it's b10-xfrout, this means DNS notify
|
|
|
+messages won't be sent to secondary servers of the zone. It's
|
|
|
+suboptimal, but not necessarily critical as the secondary servers will
|
|
|
+try to check the zone's status periodically. If it's b10-auth and the
|
|
|
+notification was needed to have it reload the corresponding zone, it's
|
|
|
+more serious because b10-auth won't be able to serve the new version
|
|
|
+of the zone unless some explicit recovery action is taken. So the
|
|
|
+administrator 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.
|
|
|
+</p></dd><dt><a name="LIBDDNS_DATASRC_ERROR"></a><span class="term">LIBDDNS_DATASRC_ERROR update client %1 failed due to data source error: %2</span></dt><dd><p>
|
|
|
+An update attempt failed due to some error in the corresponding data
|
|
|
+source. This is generally an unexpected event, but can still happen
|
|
|
+for various reasons such as DB lock contention or a failure of the
|
|
|
+backend DB server. The cause of the error is also logged. It's
|
|
|
+advisable to check the message, and, if necessary, take an appropriate
|
|
|
+action (e.g., restarting the DB server if it dies). If this message
|
|
|
+is logged the data source isn't modified due to the
|
|
|
+corresponding update request. When used by the b10-ddns, the server
|
|
|
+will return a response with an RCODE of SERVFAIL.
|
|
|
+</p></dd><dt><a name="LIBDDNS_PREREQ_FORMERR"></a><span class="term">LIBDDNS_PREREQ_FORMERR update client %1 for zone %2: Format error in prerequisite (%3). Non-zero TTL.</span></dt><dd><p>
|
|
|
+The prerequisite with the given name, class and type is not well-formed.
|
|
|
+The specific prerequisite is shown. In this case, it has a non-zero TTL value.
|
|
|
+A FORMERR error response is sent to the client.
|
|
|
+</p></dd><dt><a name="LIBDDNS_PREREQ_FORMERR_ANY"></a><span class="term">LIBDDNS_PREREQ_FORMERR_ANY update client %1 for zone %2: Format error in prerequisite (%3). Non-zero TTL or rdata found.</span></dt><dd><p>
|
|
|
+The prerequisite with the given name, class and type is not well-formed.
|
|
|
+The specific prerequisite is shown. In this case, it either has a non-zero
|
|
|
+TTL value, or has rdata fields. A FORMERR error response is sent to the client.
|
|
|
+</p></dd><dt><a name="LIBDDNS_PREREQ_FORMERR_CLASS"></a><span class="term">LIBDDNS_PREREQ_FORMERR_CLASS update client %1 for zone %2: Format error in prerequisite (%3). Bad class.</span></dt><dd><p>
|
|
|
+The prerequisite with the given name, class and type is not well-formed.
|
|
|
+The specific prerequisite is shown. In this case, the class of the
|
|
|
+prerequisite should either match the class of the zone in the Zone Section,
|
|
|
+or it should be ANY or NONE, and it is not. A FORMERR error response is sent
|
|
|
+to the client.
|
|
|
+</p></dd><dt><a name="LIBDDNS_PREREQ_FORMERR_NONE"></a><span class="term">LIBDDNS_PREREQ_FORMERR_NONE update client %1 for zone %2: Format error in prerequisite (%3). Non-zero TTL or rdata found.</span></dt><dd><p>
|
|
|
+The prerequisite with the given name, class and type is not well-formed.
|
|
|
+The specific prerequisite is shown. In this case, it either has a non-zero
|
|
|
+TTL value, or has rdata fields. A FORMERR error response is sent to the client.
|
|
|
+</p></dd><dt><a name="LIBDDNS_PREREQ_NAME_IN_USE_FAILED"></a><span class="term">LIBDDNS_PREREQ_NAME_IN_USE_FAILED update client %1 for zone %2: 'Name is in use' prerequisite not satisfied (%3), rcode: %4</span></dt><dd><p>
|
|
|
+A DNS UPDATE prerequisite was not satisfied. The specific prerequisite that
|
|
|
+was not satisfied is shown. The client is sent an error response with the
|
|
|
+given rcode.
|
|
|
+In this case, the specific prerequisite is 'Name is in use'. From RFC2136:
|
|
|
+Name is in use. At least one RR with a specified NAME (in
|
|
|
+the zone and class specified by the Zone Section) must exist.
|
|
|
+Note that this prerequisite is NOT satisfied by empty
|
|
|
+nonterminals.
|
|
|
+</p></dd><dt><a name="LIBDDNS_PREREQ_NAME_NOT_IN_USE_FAILED"></a><span class="term">LIBDDNS_PREREQ_NAME_NOT_IN_USE_FAILED update client %1 for zone %2: 'Name is not in use' (%3) prerequisite not satisfied, rcode: %4</span></dt><dd><p>
|
|
|
+A DNS UPDATE prerequisite was not satisfied. The specific prerequisite that
|
|
|
+was not satisfied is shown. The client is sent an error response with the
|
|
|
+given rcode.
|
|
|
+In this case, the specific prerequisite is 'Name is not in use'.
|
|
|
+From RFC2136:
|
|
|
+Name is not in use. No RR of any type is owned by a
|
|
|
+specified NAME. Note that this prerequisite IS satisfied by
|
|
|
+empty nonterminals.
|
|
|
+</p></dd><dt><a name="LIBDDNS_PREREQ_NOTZONE"></a><span class="term">LIBDDNS_PREREQ_NOTZONE update client %1 for zone %2: prerequisite not in zone (%3)</span></dt><dd><p>
|
|
|
+A DDNS UPDATE prerequisite has a name that does not appear to be inside
|
|
|
+the zone specified in the Zone section of the UPDATE message.
|
|
|
+The specific prerequisite is shown. A NOTZONE error response is sent to
|
|
|
+the client.
|
|
|
+</p></dd><dt><a name="LIBDDNS_PREREQ_RRSET_DOES_NOT_EXIST_FAILED"></a><span class="term">LIBDDNS_PREREQ_RRSET_DOES_NOT_EXIST_FAILED update client %1 for zone %2: 'RRset does not exist' (%3) prerequisite not satisfied, rcode: %4</span></dt><dd><p>
|
|
|
+A DNS UPDATE prerequisite was not satisfied. The specific prerequisite that
|
|
|
+was not satisfied is shown. The client is sent an error response with the
|
|
|
+given rcode.
|
|
|
+In this case, the specific prerequisite is 'RRset does not exist'.
|
|
|
+From RFC2136:
|
|
|
+RRset does not exist. No RRs with a specified NAME and TYPE
|
|
|
+(in the zone and class denoted by the Zone Section) can exist.
|
|
|
+</p></dd><dt><a name="LIBDDNS_PREREQ_RRSET_EXISTS_FAILED"></a><span class="term">LIBDDNS_PREREQ_RRSET_EXISTS_FAILED update client %1 for zone %2: 'RRset exists (value independent)' (%3) prerequisite not satisfied, rcode: %4</span></dt><dd><p>
|
|
|
+A DNS UPDATE prerequisite was not satisfied. The specific prerequisite that
|
|
|
+was not satisfied is shown. The client is sent an error response with the
|
|
|
+given rcode.
|
|
|
+In this case, the specific prerequisite is 'RRset exists (value independent)'.
|
|
|
+From RFC2136:
|
|
|
+RRset exists (value dependent). A set of RRs with a
|
|
|
+specified NAME and TYPE exists and has the same members
|
|
|
+with the same RDATAs as the RRset specified here in this
|
|
|
+Section.
|
|
|
+</p></dd><dt><a name="LIBDDNS_PREREQ_RRSET_EXISTS_VAL_FAILED"></a><span class="term">LIBDDNS_PREREQ_RRSET_EXISTS_VAL_FAILED update client %1 for zone %2: 'RRset exists (value dependent)' (%3) prerequisite not satisfied, rcode: %4</span></dt><dd><p>
|
|
|
+A DNS UPDATE prerequisite was not satisfied. The specific prerequisite that
|
|
|
+was not satisfied is shown. The client is sent an error response with the
|
|
|
+given rcode.
|
|
|
+In this case, the specific prerequisite is 'RRset exists (value dependent)'.
|
|
|
+From RFC2136:
|
|
|
+RRset exists (value independent). At least one RR with a
|
|
|
+specified NAME and TYPE (in the zone and class specified by
|
|
|
+the Zone Section) must exist.
|
|
|
+</p></dd><dt><a name="LIBDDNS_UPDATE_ADD_BAD_TYPE"></a><span class="term">LIBDDNS_UPDATE_ADD_BAD_TYPE update client %1 for zone %2: update addition RR bad type: %3</span></dt><dd><p>
|
|
|
+The Update section of a DDNS update message contains a statement
|
|
|
+that tries to add a record of an invalid type. Most likely the
|
|
|
+record has an RRType that is considered a 'meta' type, which
|
|
|
+cannot be zone content data. The specific record is shown.
|
|
|
+A FORMERR response is sent back to the client.
|
|
|
+</p></dd><dt><a name="LIBDDNS_UPDATE_APPROVED"></a><span class="term">LIBDDNS_UPDATE_APPROVED update client %1 for zone %2 approved</span></dt><dd><p>
|
|
|
+Debug message. An update request was approved in terms of the zone's
|
|
|
+update ACL.
|
|
|
+</p></dd><dt><a name="LIBDDNS_UPDATE_BAD_CLASS"></a><span class="term">LIBDDNS_UPDATE_BAD_CLASS update client %1 for zone %2: bad class in update RR: %3</span></dt><dd><p>
|
|
|
+The Update section of a DDNS update message contains an RRset with
|
|
|
+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.
|
|
|
+</p></dd><dt><a name="LIBDDNS_UPDATE_DATASRC_ERROR"></a><span class="term">LIBDDNS_UPDATE_DATASRC_ERROR error in datasource during DDNS update: %1</span></dt><dd><p>
|
|
|
+An error occured while committing the DDNS update changes to the
|
|
|
+datasource. The specific error is printed. A SERVFAIL response is sent
|
|
|
+back to the client.
|
|
|
+</p></dd><dt><a name="LIBDDNS_UPDATE_DELETE_BAD_TYPE"></a><span class="term">LIBDDNS_UPDATE_DELETE_BAD_TYPE update client %1 for zone %2: update deletion RR bad type: %3</span></dt><dd><p>
|
|
|
+The Update section of a DDNS update message contains a statement
|
|
|
+that tries to delete an rrset of an invalid type. Most likely the
|
|
|
+record has an RRType that is considered a 'meta' type, which
|
|
|
+cannot be zone content data. The specific record is shown.
|
|
|
+A FORMERR response is sent back to the client.
|
|
|
+</p></dd><dt><a name="LIBDDNS_UPDATE_DELETE_NONZERO_TTL"></a><span class="term">LIBDDNS_UPDATE_DELETE_NONZERO_TTL update client %1 for zone %2: update deletion RR has non-zero TTL: %3</span></dt><dd><p>
|
|
|
+The Update section of a DDNS update message contains a 'delete rrset'
|
|
|
+statement with a non-zero TTL. This is not allowed by the protocol.
|
|
|
+A FORMERR response is sent back to the client.
|
|
|
+</p></dd><dt><a name="LIBDDNS_UPDATE_DELETE_RRSET_NOT_EMPTY"></a><span class="term">LIBDDNS_UPDATE_DELETE_RRSET_NOT_EMPTY update client %1 for zone %2: update deletion RR contains data %3</span></dt><dd><p>
|
|
|
+The Update section of a DDNS update message contains a 'delete rrset'
|
|
|
+statement with a non-empty RRset. This is not allowed by the protocol.
|
|
|
+A FORMERR response is sent back to the client.
|
|
|
+</p></dd><dt><a name="LIBDDNS_UPDATE_DELETE_RR_BAD_TYPE"></a><span class="term">LIBDDNS_UPDATE_DELETE_RR_BAD_TYPE update client %1 for zone %2: update deletion RR bad type: %3</span></dt><dd><p>
|
|
|
+The Update section of a DDNS update message contains a statement
|
|
|
+that tries to delete one or more rrs of an invalid type. Most
|
|
|
+likely the records have an RRType that is considered a 'meta'
|
|
|
+type, which cannot be zone content data. The specific record is
|
|
|
+shown. A FORMERR response is sent back to the client.
|
|
|
+</p></dd><dt><a name="LIBDDNS_UPDATE_DELETE_RR_NONZERO_TTL"></a><span class="term">LIBDDNS_UPDATE_DELETE_RR_NONZERO_TTL update client %1 for zone %2: update deletion RR has non-zero TTL: %3</span></dt><dd><p>
|
|
|
+The Update section of a DDNS update message contains a 'delete rrs'
|
|
|
+statement with a non-zero TTL. This is not allowed by the protocol.
|
|
|
+A FORMERR response is sent back to the client.
|
|
|
+</p></dd><dt><a name="LIBDDNS_UPDATE_DENIED"></a><span class="term">LIBDDNS_UPDATE_DENIED update client %1 for zone %2 denied</span></dt><dd><p>
|
|
|
+Informational message. An update request was denied because it was
|
|
|
+rejected by the zone's update ACL. When this library is used by
|
|
|
+b10-ddns, the server will respond to the request with an RCODE of
|
|
|
+REFUSED as described in Section 3.3 of RFC2136.
|
|
|
+</p></dd><dt><a name="LIBDDNS_UPDATE_DROPPED"></a><span class="term">LIBDDNS_UPDATE_DROPPED update client %1 for zone %2 dropped</span></dt><dd><p>
|
|
|
+Informational message. An update request was denied because it was
|
|
|
+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.
|
|
|
+</p></dd><dt><a name="LIBDDNS_UPDATE_ERROR"></a><span class="term">LIBDDNS_UPDATE_ERROR update client %1 for zone %2: %3</span></dt><dd><p>
|
|
|
+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
|
|
|
+problem in the client implementation or an interoperability issue
|
|
|
+with this implementation. The client's address, the zone name and
|
|
|
+class, and description of the error are logged.
|
|
|
+</p></dd><dt><a name="LIBDDNS_UPDATE_FORWARD_FAIL"></a><span class="term">LIBDDNS_UPDATE_FORWARD_FAIL update client %1 for zone %2: update forwarding not supported</span></dt><dd><p>
|
|
|
+Debug message. An update request is sent to a secondary server. This
|
|
|
+is not necessarily invalid, but this implementation does not yet
|
|
|
+support update forwarding as specified in Section 6 of RFC2136 and it
|
|
|
+will simply return a response with an RCODE of NOTIMP to the client.
|
|
|
+The client's address and the zone name/class are logged.
|
|
|
+</p></dd><dt><a name="LIBDDNS_UPDATE_NOTAUTH"></a><span class="term">LIBDDNS_UPDATE_NOTAUTH update client %1 for zone %2: not authoritative for update zone</span></dt><dd><p>
|
|
|
+Debug message. An update request was received for a zone for which
|
|
|
+the receiving server doesn't have authority. In theory this is an
|
|
|
+unexpected event, but there are client implementations that could send
|
|
|
+update requests carelessly, so it may not necessarily be so uncommon
|
|
|
+in practice. If possible, you may want to check the implementation or
|
|
|
+configuration of those clients to suppress the requests. As specified
|
|
|
+in Section 3.1 of RFC2136, the receiving server will return a response
|
|
|
+with an RCODE of NOTAUTH.
|
|
|
+</p></dd><dt><a name="LIBDDNS_UPDATE_NOTZONE"></a><span class="term">LIBDDNS_UPDATE_NOTZONE update client %1 for zone %2: update RR out of zone %3</span></dt><dd><p>
|
|
|
+A DDNS UPDATE record has a name that does not appear to be inside
|
|
|
+the zone specified in the Zone section of the UPDATE message.
|
|
|
+The specific update record is shown. A NOTZONE error response is
|
|
|
+sent to the client.
|
|
|
+</p></dd><dt><a name="LIBDDNS_UPDATE_PREREQUISITE_FAILED"></a><span class="term">LIBDDNS_UPDATE_PREREQUISITE_FAILED prerequisite failed in update client %1 for zone %2: result code %3</span></dt><dd><p>
|
|
|
+The handling of the prerequisite section (RFC2136 Section 3.2) found
|
|
|
+that one of the prerequisites was not satisfied. The result code
|
|
|
+should give more information on what prerequisite type failed.
|
|
|
+If the result code is FORMERR, the prerequisite section was not well-formed.
|
|
|
+An error response with the given result code is sent back to the client.
|
|
|
+</p></dd><dt><a name="LIBDDNS_UPDATE_UNCAUGHT_EXCEPTION"></a><span class="term">LIBDDNS_UPDATE_UNCAUGHT_EXCEPTION update client %1 for zone %2: uncaught exception while processing update section: %3</span></dt><dd><p>
|
|
|
+An uncaught exception was encountered while processing the Update
|
|
|
+section of a DDNS message. The specific exception is shown in the log message.
|
|
|
+To make sure DDNS service is not interrupted, this problem is caught instead
|
|
|
+of reraised; The update is aborted, and a SERVFAIL is sent back to the client.
|
|
|
+This is most probably a bug in the DDNS code, but *could* be caused by
|
|
|
+the data source.
|
|
|
</p></dd><dt><a name="LIBXFRIN_DIFFERENT_TTL"></a><span class="term">LIBXFRIN_DIFFERENT_TTL multiple data with different TTLs (%1, %2) on %3/%4/%5. Adjusting %2 -> %1.</span></dt><dd><p>
|
|
|
The xfrin module received an update containing multiple rdata changes for the
|
|
|
same RRset. But the TTLs of these don't match each other. As we combine them
|
|
|
@@ -1634,6 +1966,8 @@ the reason given.
|
|
|
An invalid message identification (ID) has been found during the read of
|
|
|
a message file. Message IDs should comprise only alphanumeric characters
|
|
|
and the underscore, and should not start with a digit.
|
|
|
+</p></dd><dt><a name="LOG_LOCK_TEST_MESSAGE"></a><span class="term">LOG_LOCK_TEST_MESSAGE this is a test message.</span></dt><dd><p>
|
|
|
+This is a log message used in testing.
|
|
|
</p></dd><dt><a name="LOG_NAMESPACE_EXTRA_ARGS"></a><span class="term">LOG_NAMESPACE_EXTRA_ARGS line %1: $NAMESPACE directive has too many arguments</span></dt><dd><p>
|
|
|
The $NAMESPACE directive in a message file takes a single argument, a
|
|
|
namespace in which all the generated symbol names are placed. This error
|
|
|
@@ -1835,6 +2169,30 @@ an answer with a different given type and class.
|
|
|
</p><p>
|
|
|
This message indicates an internal error in the NSAS. Please raise a
|
|
|
bug report.
|
|
|
+</p></dd><dt><a name="PYSERVER_COMMON_AUTH_CONFIG_NAME_PARSER_ERROR"></a><span class="term">PYSERVER_COMMON_AUTH_CONFIG_NAME_PARSER_ERROR Invalid name when parsing Auth configuration: %1</span></dt><dd><p>
|
|
|
+There was an invalid name when parsing Auth configuration.
|
|
|
+</p></dd><dt><a name="PYSERVER_COMMON_AUTH_CONFIG_RRCLASS_ERROR"></a><span class="term">PYSERVER_COMMON_AUTH_CONFIG_RRCLASS_ERROR Invalid RRClass when parsing Auth configuration: %1</span></dt><dd><p>
|
|
|
+There was an invalid RR class when parsing Auth configuration.
|
|
|
+</p></dd><dt><a name="PYSERVER_COMMON_DNS_TCP_SEND_DONE"></a><span class="term">PYSERVER_COMMON_DNS_TCP_SEND_DONE completed sending TCP message to %1 (%2 bytes in total)</span></dt><dd><p>
|
|
|
+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.
|
|
|
+</p></dd><dt><a name="PYSERVER_COMMON_DNS_TCP_SEND_ERROR"></a><span class="term">PYSERVER_COMMON_DNS_TCP_SEND_ERROR failed to send TCP message to %1 (%2/%3 bytes sent): %4</span></dt><dd><p>
|
|
|
+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
|
|
|
+administrator may want to examine the cause of the failure, which is
|
|
|
+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.
|
|
|
+</p></dd><dt><a name="PYSERVER_COMMON_DNS_TCP_SEND_PENDING"></a><span class="term">PYSERVER_COMMON_DNS_TCP_SEND_PENDING sent part TCP message to %1 (up to %2/%3 bytes)</span></dt><dd><p>
|
|
|
+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.
|
|
|
</p></dd><dt><a name="PYSERVER_COMMON_TSIG_KEYRING_DEINIT"></a><span class="term">PYSERVER_COMMON_TSIG_KEYRING_DEINIT Deinitializing global TSIG keyring</span></dt><dd><p>
|
|
|
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.
|
|
|
@@ -2402,10 +2760,6 @@ is unknown in the implementation. The most likely cause is an
|
|
|
installation problem, where the specification file stats.spec is
|
|
|
from a different version of BIND 10 than the stats module itself.
|
|
|
Please check your installation.
|
|
|
-</p></dd><dt><a name="XFRIN_AUTH_CONFIG_NAME_PARSER_ERROR"></a><span class="term">XFRIN_AUTH_CONFIG_NAME_PARSER_ERROR Invalid name when parsing Auth configuration: %1</span></dt><dd><p>
|
|
|
-There was an invalid name when parsing Auth configuration.
|
|
|
-</p></dd><dt><a name="XFRIN_AUTH_CONFIG_RRCLASS_ERROR"></a><span class="term">XFRIN_AUTH_CONFIG_RRCLASS_ERROR Invalid RRClass when parsing Auth configuration: %1</span></dt><dd><p>
|
|
|
-There was an invalid RR class when parsing Auth configuration.
|
|
|
</p></dd><dt><a name="XFRIN_AUTH_LOADZONE"></a><span class="term">XFRIN_AUTH_LOADZONE sending Auth loadzone for origin=%1, class=%2, datasrc=%3</span></dt><dd><p>
|
|
|
There was a successful zone transfer, and the zone is served by b10-auth
|
|
|
in the in-memory data source using sqlite3 as a backend. We send the
|
|
|
@@ -2689,11 +3043,15 @@ do not understand or support. The xfrout request will be ignored.
|
|
|
In general, this should only occur for unexpected problems like
|
|
|
memory allocation failures, as the query should already have been
|
|
|
parsed by the b10-auth daemon, before it was passed here.
|
|
|
-</p></dd><dt><a name="XFROUT_PROCESS_REQUEST_ERROR"></a><span class="term">XFROUT_PROCESS_REQUEST_ERROR error processing transfer request: %2</span></dt><dd><p>
|
|
|
-There was an error processing a transfer request. The error is included
|
|
|
-in the log message, but at this point no specific information other
|
|
|
-than that could be given. This points to incomplete exception handling
|
|
|
-in the code.
|
|
|
+</p></dd><dt><a name="XFROUT_PROCESS_REQUEST_ERROR"></a><span class="term">XFROUT_PROCESS_REQUEST_ERROR error processing transfer request: %1</span></dt><dd><p>
|
|
|
+There was an error in receiving a transfer request from b10-auth.
|
|
|
+This is generally an unexpected event, but is possible when, for
|
|
|
+example, b10-auth terminates in the middle of forwarding the request.
|
|
|
+When this happens it's unlikely to be recoverable with the same
|
|
|
+communication session with b10-auth, so b10-xfrout drops it and
|
|
|
+waits for a new session. In any case, this error indicates that
|
|
|
+there's something very wrong in the system, so it's advisable to check
|
|
|
+the over all status of the BIND 10 system.
|
|
|
</p></dd><dt><a name="XFROUT_QUERY_DROPPED"></a><span class="term">XFROUT_QUERY_DROPPED %1 client %2: request to transfer %3 dropped</span></dt><dd><p>
|
|
|
The xfrout process silently dropped a request to transfer zone to
|
|
|
given host. This is required by the ACLs. The %2 represents the IP
|
|
|
@@ -2718,9 +3076,16 @@ The xfrout daemon received a shutdown command from the command channel
|
|
|
and will now shut down.
|
|
|
</p></dd><dt><a name="XFROUT_RECEIVE_FILE_DESCRIPTOR_ERROR"></a><span class="term">XFROUT_RECEIVE_FILE_DESCRIPTOR_ERROR error receiving the file descriptor for an XFR connection</span></dt><dd><p>
|
|
|
There was an error receiving the file descriptor for the transfer
|
|
|
-request. Normally, the request is received by b10-auth, and passed on
|
|
|
-to the xfrout daemon, so it can answer directly. However, there was a
|
|
|
-problem receiving this file descriptor. The request will be ignored.
|
|
|
+request from b10-auth. There can be several reasons for this, but
|
|
|
+the most likely cause is that b10-auth terminates for some reason
|
|
|
+(maybe it's a bug of b10-auth, maybe it's an intentional restart by
|
|
|
+the administrator), so depending on how this happens it may or may not
|
|
|
+be a serious error. But in any case this is not expected to happen
|
|
|
+frequently, and it's advisable to figure out how this happened if
|
|
|
+this message is logged. Even if this error happens xfrout will reset
|
|
|
+its internal state and will keep receiving further requests. So
|
|
|
+if it's just a temporary restart of b10-auth the administrator does
|
|
|
+not have to do anything.
|
|
|
</p></dd><dt><a name="XFROUT_REMOVE_OLD_UNIX_SOCKET_FILE_ERROR"></a><span class="term">XFROUT_REMOVE_OLD_UNIX_SOCKET_FILE_ERROR error removing unix socket file %1: %2</span></dt><dd><p>
|
|
|
The unix socket file xfrout needs for contact with the auth daemon
|
|
|
already exists, and needs to be removed first, but there is a problem
|
Jeremy C. Reed