|
@@ -467,6 +467,14 @@ and it is entering the main loop, waiting for queries to arrive.
|
|
|
</para></listitem>
|
|
|
</varlistentry>
|
|
|
|
|
|
+<varlistentry id="AUTH_SHUTDOWN">
|
|
|
+<term>AUTH_SHUTDOWN asked to stop, doing so</term>
|
|
|
+<listitem><para>
|
|
|
+This is a debug message indicating the server was asked to shut down and it is
|
|
|
+complying to the request.
|
|
|
+</para></listitem>
|
|
|
+</varlistentry>
|
|
|
+
|
|
|
<varlistentry id="AUTH_SQLITE3">
|
|
|
<term>AUTH_SQLITE3 nothing to do for loading sqlite3</term>
|
|
|
<listitem><para>
|
|
@@ -1766,6 +1774,26 @@ a bug report.
|
|
|
</para></listitem>
|
|
|
</varlistentry>
|
|
|
|
|
|
+<varlistentry id="CONFIG_CCSESSION_STOPPING">
|
|
|
+<term>CONFIG_CCSESSION_STOPPING error sending stopping message: %1</term>
|
|
|
+<listitem><para>
|
|
|
+There was a problem when sending a message signaling that the module using
|
|
|
+this CCSession is stopping. This message is sent so that the rest of the
|
|
|
+system is aware that the module is no longer running. Apart from logging
|
|
|
+this message, the error itself is ignored, and the ModuleCCSession is
|
|
|
+still stopped. The specific exception message is printed.
|
|
|
+</para></listitem>
|
|
|
+</varlistentry>
|
|
|
+
|
|
|
+<varlistentry id="CONFIG_CCSESSION_STOPPING_UNKNOWN">
|
|
|
+<term>CONFIG_CCSESSION_STOPPING_UNKNOWN unknown error sending stopping message</term>
|
|
|
+<listitem><para>
|
|
|
+Similar to CONFIG_CCSESSION_STOPPING, but in this case the exception that
|
|
|
+is seen is not a standard exception, and further information is unknown.
|
|
|
+This is a bug.
|
|
|
+</para></listitem>
|
|
|
+</varlistentry>
|
|
|
+
|
|
|
<varlistentry id="CONFIG_GET_FAIL">
|
|
|
<term>CONFIG_GET_FAIL error getting configuration from cfgmgr: %1</term>
|
|
|
<listitem><para>
|
|
@@ -1873,6 +1901,28 @@ is included in the message.
|
|
|
</para></listitem>
|
|
|
</varlistentry>
|
|
|
|
|
|
+<varlistentry id="CONFIG_SESSION_STOPPING_FAILED">
|
|
|
+<term>CONFIG_SESSION_STOPPING_FAILED error sending stopping message: %1</term>
|
|
|
+<listitem><para>
|
|
|
+There was a problem when sending a message signaling that the module using
|
|
|
+this CCSession is stopping. This message is sent so that the rest of the
|
|
|
+system is aware that the module is no longer running. Apart from logging
|
|
|
+this message, the error itself is ignored, and the ModuleCCSession is
|
|
|
+still stopped. The specific exception message is printed.
|
|
|
+</para></listitem>
|
|
|
+</varlistentry>
|
|
|
+
|
|
|
+<varlistentry id="DATASRC_BAD_NSEC3_NAME">
|
|
|
+<term>DATASRC_BAD_NSEC3_NAME NSEC3 record has a bad owner name '%1'</term>
|
|
|
+<listitem><para>
|
|
|
+The software refuses to load NSEC3 records into a wildcard domain or
|
|
|
+the owner name has two or more labels below the zone origin.
|
|
|
+It isn't explicitly forbidden, but no sane zone wouldn have such names
|
|
|
+for NSEC3. BIND 9 also refuses NSEC3 at wildcard, so this behavior is
|
|
|
+compatible with BIND 9.
|
|
|
+</para></listitem>
|
|
|
+</varlistentry>
|
|
|
+
|
|
|
<varlistentry id="DATASRC_CACHE_CREATE">
|
|
|
<term>DATASRC_CACHE_CREATE creating the hotspot cache</term>
|
|
|
<listitem><para>
|
|
@@ -2177,15 +2227,6 @@ its class and the database name are printed.
|
|
|
</para></listitem>
|
|
|
</varlistentry>
|
|
|
|
|
|
-<varlistentry id="DATASRC_DATABASE_UPDATER_COMMIT (1)">
|
|
|
-<term>DATASRC_DATABASE_UPDATER_COMMIT (1) updates committed for '%1/%2' on %3</term>
|
|
|
-<listitem><para>
|
|
|
-Debug information. A set of updates to a zone has been successfully
|
|
|
-committed to the corresponding database backend. The zone name,
|
|
|
-its class and the database name are printed.
|
|
|
-</para></listitem>
|
|
|
-</varlistentry>
|
|
|
-
|
|
|
<varlistentry id="DATASRC_DATABASE_UPDATER_CREATED">
|
|
|
<term>DATASRC_DATABASE_UPDATER_CREATED zone updater created for '%1/%2' on %3</term>
|
|
|
<listitem><para>
|
|
@@ -2194,14 +2235,6 @@ the shown zone on the shown backend database.
|
|
|
</para></listitem>
|
|
|
</varlistentry>
|
|
|
|
|
|
-<varlistentry id="DATASRC_DATABASE_UPDATER_CREATED (1)">
|
|
|
-<term>DATASRC_DATABASE_UPDATER_CREATED (1) zone updater created for '%1/%2' on %3</term>
|
|
|
-<listitem><para>
|
|
|
-Debug information. A zone updater object is created to make updates to
|
|
|
-the shown zone on the shown backend database.
|
|
|
-</para></listitem>
|
|
|
-</varlistentry>
|
|
|
-
|
|
|
<varlistentry id="DATASRC_DATABASE_UPDATER_DESTROYED">
|
|
|
<term>DATASRC_DATABASE_UPDATER_DESTROYED zone updater destroyed for '%1/%2' on %3</term>
|
|
|
<listitem><para>
|
|
@@ -2211,15 +2244,6 @@ database.
|
|
|
</para></listitem>
|
|
|
</varlistentry>
|
|
|
|
|
|
-<varlistentry id="DATASRC_DATABASE_UPDATER_DESTROYED (1)">
|
|
|
-<term>DATASRC_DATABASE_UPDATER_DESTROYED (1) zone updater destroyed for '%1/%2' on %3</term>
|
|
|
-<listitem><para>
|
|
|
-Debug information. A zone updater object is destroyed, either successfully
|
|
|
-or after failure of, making updates to the shown zone on the shown backend
|
|
|
-database.
|
|
|
-</para></listitem>
|
|
|
-</varlistentry>
|
|
|
-
|
|
|
<varlistentry id="DATASRC_DATABASE_UPDATER_ROLLBACK">
|
|
|
<term>DATASRC_DATABASE_UPDATER_ROLLBACK zone updates roll-backed for '%1/%2' on %3</term>
|
|
|
<listitem><para>
|
|
@@ -2232,18 +2256,6 @@ the underlying database name are shown in the log message.
|
|
|
</para></listitem>
|
|
|
</varlistentry>
|
|
|
|
|
|
-<varlistentry id="DATASRC_DATABASE_UPDATER_ROLLBACK (1)">
|
|
|
-<term>DATASRC_DATABASE_UPDATER_ROLLBACK (1) zone updates roll-backed for '%1/%2' on %3</term>
|
|
|
-<listitem><para>
|
|
|
-A zone updater is being destroyed without committing the changes.
|
|
|
-This would typically mean the update attempt was aborted due to some
|
|
|
-error, but may also be a bug of the application that forgets committing
|
|
|
-the changes. The intermediate changes made through the updater won't
|
|
|
-be applied to the underlying database. The zone name, its class, and
|
|
|
-the underlying database name are shown in the log message.
|
|
|
-</para></listitem>
|
|
|
-</varlistentry>
|
|
|
-
|
|
|
<varlistentry id="DATASRC_DATABASE_UPDATER_ROLLBACKFAIL">
|
|
|
<term>DATASRC_DATABASE_UPDATER_ROLLBACKFAIL failed to roll back zone updates for '%1/%2' on %3: %4</term>
|
|
|
<listitem><para>
|
|
@@ -2261,23 +2273,6 @@ database module are shown in the log message.
|
|
|
</para></listitem>
|
|
|
</varlistentry>
|
|
|
|
|
|
-<varlistentry id="DATASRC_DATABASE_UPDATER_ROLLBACKFAIL (1)">
|
|
|
-<term>DATASRC_DATABASE_UPDATER_ROLLBACKFAIL (1) failed to roll back zone updates for '%1/%2' on %3: %4</term>
|
|
|
-<listitem><para>
|
|
|
-A zone updater is being destroyed without committing the changes to
|
|
|
-the database, and attempts to rollback incomplete updates, but it
|
|
|
-unexpectedly fails. The higher level implementation does not expect
|
|
|
-it to fail, so this means either a serious operational error in the
|
|
|
-underlying data source (such as a system failure of a database) or
|
|
|
-software bug in the underlying data source implementation. In either
|
|
|
-case if this message is logged the administrator should carefully
|
|
|
-examine the underlying data source to see what exactly happens and
|
|
|
-whether the data is still valid. The zone name, its class, and the
|
|
|
-underlying database name as well as the error message thrown from the
|
|
|
-database module are shown in the log message.
|
|
|
-</para></listitem>
|
|
|
-</varlistentry>
|
|
|
-
|
|
|
<varlistentry id="DATASRC_DATABASE_WILDCARD_ANY">
|
|
|
<term>DATASRC_DATABASE_WILDCARD_ANY search in datasource %1 resulted in wildcard match type ANY on %2</term>
|
|
|
<listitem><para>
|
|
@@ -2497,6 +2492,46 @@ Debug information. A search for the requested RRset is being started.
|
|
|
</para></listitem>
|
|
|
</varlistentry>
|
|
|
|
|
|
+<varlistentry id="DATASRC_MEM_FINDNSEC3">
|
|
|
+<term>DATASRC_MEM_FINDNSEC3 finding NSEC3 for %1, mode %2</term>
|
|
|
+<listitem><para>
|
|
|
+Debug information. A search in an in-memory data source for NSEC3 that
|
|
|
+matches or covers the given name is being started.
|
|
|
+</para></listitem>
|
|
|
+</varlistentry>
|
|
|
+
|
|
|
+<varlistentry id="DATASRC_MEM_FINDNSEC3_COVER">
|
|
|
+<term>DATASRC_MEM_FINDNSEC3_COVER found a covering NSEC3 for %1: %2</term>
|
|
|
+<listitem><para>
|
|
|
+Debug information. An NSEC3 that covers the given name is found and
|
|
|
+being returned. The found NSEC3 RRset is also displayed.
|
|
|
+</para></listitem>
|
|
|
+</varlistentry>
|
|
|
+
|
|
|
+<varlistentry id="DATASRC_MEM_FINDNSEC3_MATCH">
|
|
|
+<term>DATASRC_MEM_FINDNSEC3_MATCH found a matching NSEC3 for %1 at label count %2: %3</term>
|
|
|
+<listitem><para>
|
|
|
+Debug information. An NSEC3 that matches (a possibly superdomain of)
|
|
|
+the given name is found and being returned. 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_MEM_FINDNSEC3_TRYHASH).
|
|
|
+The found NSEC3 RRset is also displayed.
|
|
|
+</para></listitem>
|
|
|
+</varlistentry>
|
|
|
+
|
|
|
+<varlistentry id="DATASRC_MEM_FINDNSEC3_TRYHASH">
|
|
|
+<term>DATASRC_MEM_FINDNSEC3_TRYHASH looking for NSEC3 for %1 at label count %2 (hash %3)</term>
|
|
|
+<listitem><para>
|
|
|
+Debug information. In an attempt of finding an NSEC3 for the give name,
|
|
|
+(a possibly superdomain of) the name is hashed and searched for in the
|
|
|
+NSEC3 name space. When the shown label count is smaller than that of the
|
|
|
+shown name, the search tries the superdomain name that share the shown
|
|
|
+(higher) label count of the shown name (e.g., for
|
|
|
+www.example.com. with shown label count of 3, example.com. is being
|
|
|
+tried).
|
|
|
+</para></listitem>
|
|
|
+</varlistentry>
|
|
|
+
|
|
|
<varlistentry id="DATASRC_MEM_FIND_ZONE">
|
|
|
<term>DATASRC_MEM_FIND_ZONE looking for zone '%1'</term>
|
|
|
<listitem><para>
|
|
@@ -2519,6 +2554,18 @@ Debug information. The requested domain does not exist.
|
|
|
</para></listitem>
|
|
|
</varlistentry>
|
|
|
|
|
|
+<varlistentry id="DATASRC_MEM_NO_NSEC3PARAM">
|
|
|
+<term>DATASRC_MEM_NO_NSEC3PARAM NSEC3PARAM is missing for NSEC3-signed zone %1/%2</term>
|
|
|
+<listitem><para>
|
|
|
+The in-memory data source has loaded a zone signed with NSEC3 RRs,
|
|
|
+but it doesn't have a NSEC3PARAM RR at the zone origin. It's likely that
|
|
|
+the zone is somehow broken, but this RR is not necessarily needed for
|
|
|
+handling lookups with NSEC3 in this data source, so it accepts the given
|
|
|
+content of the zone. Nevertheless the administrator should look into
|
|
|
+the integrity of the zone data.
|
|
|
+</para></listitem>
|
|
|
+</varlistentry>
|
|
|
+
|
|
|
<varlistentry id="DATASRC_MEM_NS_ENCOUNTERED">
|
|
|
<term>DATASRC_MEM_NS_ENCOUNTERED encountered a NS</term>
|
|
|
<listitem><para>
|
|
@@ -2570,11 +2617,13 @@ Debug information. The requested record was found.
|
|
|
</varlistentry>
|
|
|
|
|
|
<varlistentry id="DATASRC_MEM_SUPER_STOP">
|
|
|
-<term>DATASRC_MEM_SUPER_STOP stopped at superdomain '%1', domain '%2' is empty</term>
|
|
|
+<term>DATASRC_MEM_SUPER_STOP stopped as '%1' is superdomain of a zone node, meaning it's empty</term>
|
|
|
<listitem><para>
|
|
|
-Debug information. The search stopped at a superdomain of the requested
|
|
|
-domain. The domain is an empty nonterminal, therefore it is treated as NXRRSET
|
|
|
-case (eg. the domain exists, but it doesn't have the requested record type).
|
|
|
+Debug information. The search stopped because the requested domain was
|
|
|
+detected to be a superdomain of some existing node of zone (while there
|
|
|
+was no exact match). This means that the domain is an empty nonterminal,
|
|
|
+therefore it is treated as NXRRSET case (eg. the domain exists, but it
|
|
|
+doesn't have the requested record type).
|
|
|
</para></listitem>
|
|
|
</varlistentry>
|
|
|
|
|
@@ -2925,7 +2974,7 @@ the specific error already.
|
|
|
</varlistentry>
|
|
|
|
|
|
<varlistentry id="DATASRC_QUERY_RRSIG">
|
|
|
-<term>DATASRC_QUERY_RRSIG unable to answer RRSIG query</term>
|
|
|
+<term>DATASRC_QUERY_RRSIG unable to answer RRSIG query for %1</term>
|
|
|
<listitem><para>
|
|
|
The server is unable to answer a direct query for RRSIG type, but was asked
|
|
|
to do so.
|
|
@@ -3232,6 +3281,16 @@ generated.
|
|
|
</para></listitem>
|
|
|
</varlistentry>
|
|
|
|
|
|
+<varlistentry id="DDNS_ACCEPT_FAILURE">
|
|
|
+<term>DDNS_ACCEPT_FAILURE error accepting a connection: %1</term>
|
|
|
+<listitem><para>
|
|
|
+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.
|
|
|
+</para></listitem>
|
|
|
+</varlistentry>
|
|
|
+
|
|
|
<varlistentry id="DDNS_CC_SESSION_ERROR">
|
|
|
<term>DDNS_CC_SESSION_ERROR error reading from cc channel: %1</term>
|
|
|
<listitem><para>
|
|
@@ -3257,6 +3316,17 @@ startup time. Details of the error are included in the log message.
|
|
|
</para></listitem>
|
|
|
</varlistentry>
|
|
|
|
|
|
+<varlistentry id="DDNS_DROP_CONN">
|
|
|
+<term>DDNS_DROP_CONN dropping connection on file descriptor %1 because of error %2</term>
|
|
|
+<listitem><para>
|
|
|
+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.
|
|
|
+</para></listitem>
|
|
|
+</varlistentry>
|
|
|
+
|
|
|
<varlistentry id="DDNS_MODULECC_SESSION_ERROR">
|
|
|
<term>DDNS_MODULECC_SESSION_ERROR error encountered by configuration/command module: %1</term>
|
|
|
<listitem><para>
|
|
@@ -3268,6 +3338,16 @@ will also be displayed.
|
|
|
</para></listitem>
|
|
|
</varlistentry>
|
|
|
|
|
|
+<varlistentry id="DDNS_NEW_CONN">
|
|
|
+<term>DDNS_NEW_CONN new connection on file descriptor %1 from %2</term>
|
|
|
+<listitem><para>
|
|
|
+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.
|
|
|
+</para></listitem>
|
|
|
+</varlistentry>
|
|
|
+
|
|
|
<varlistentry id="DDNS_RECEIVED_SHUTDOWN_COMMAND">
|
|
|
<term>DDNS_RECEIVED_SHUTDOWN_COMMAND shutdown command received</term>
|
|
|
<listitem><para>
|
|
@@ -3284,6 +3364,15 @@ and updates.
|
|
|
</para></listitem>
|
|
|
</varlistentry>
|
|
|
|
|
|
+<varlistentry id="DDNS_SESSION">
|
|
|
+<term>DDNS_SESSION session arrived on file descriptor %1</term>
|
|
|
+<listitem><para>
|
|
|
+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
|
|
|
+following log messages to see what of it.
|
|
|
+</para></listitem>
|
|
|
+</varlistentry>
|
|
|
+
|
|
|
<varlistentry id="DDNS_SHUTDOWN">
|
|
|
<term>DDNS_SHUTDOWN ddns server shutting down</term>
|
|
|
<listitem><para>
|
|
@@ -3826,6 +3915,32 @@ bug report.
|
|
|
</para></listitem>
|
|
|
</varlistentry>
|
|
|
|
|
|
+<varlistentry id="PYSERVER_COMMON_TSIG_KEYRING_DEINIT">
|
|
|
+<term>PYSERVER_COMMON_TSIG_KEYRING_DEINIT Deinitializing global TSIG keyring</term>
|
|
|
+<listitem><para>
|
|
|
+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.
|
|
|
+</para></listitem>
|
|
|
+</varlistentry>
|
|
|
+
|
|
|
+<varlistentry id="PYSERVER_COMMON_TSIG_KEYRING_INIT">
|
|
|
+<term>PYSERVER_COMMON_TSIG_KEYRING_INIT Initializing global TSIG keyring</term>
|
|
|
+<listitem><para>
|
|
|
+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.
|
|
|
+</para></listitem>
|
|
|
+</varlistentry>
|
|
|
+
|
|
|
+<varlistentry id="PYSERVER_COMMON_TSIG_KEYRING_UPDATE">
|
|
|
+<term>PYSERVER_COMMON_TSIG_KEYRING_UPDATE Updating global TSIG keyring</term>
|
|
|
+<listitem><para>
|
|
|
+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.
|
|
|
+</para></listitem>
|
|
|
+</varlistentry>
|
|
|
+
|
|
|
<varlistentry id="RESLIB_ANSWER">
|
|
|
<term>RESLIB_ANSWER answer received in response to query for <%1></term>
|
|
|
<listitem><para>
|
|
@@ -4571,6 +4686,14 @@ This informational message is output when the resolver has shut down.
|
|
|
</para></listitem>
|
|
|
</varlistentry>
|
|
|
|
|
|
+<varlistentry id="RESOLVER_SHUTDOWN (1)">
|
|
|
+<term>RESOLVER_SHUTDOWN (1) asked to shut down, doing so</term>
|
|
|
+<listitem><para>
|
|
|
+A debug message noting that the server was asked to terminate and is
|
|
|
+complying to the request.
|
|
|
+</para></listitem>
|
|
|
+</varlistentry>
|
|
|
+
|
|
|
<varlistentry id="RESOLVER_STARTED">
|
|
|
<term>RESOLVER_STARTED resolver started</term>
|
|
|
<listitem><para>
|
|
@@ -4605,7 +4728,7 @@ a message to the sender with the RCODE set to NOTIMP.
|
|
|
</varlistentry>
|
|
|
|
|
|
<varlistentry id="SOCKETREQUESTOR_CREATED">
|
|
|
-<term>SOCKETREQUESTOR_CREATED Socket requestor created</term>
|
|
|
+<term>SOCKETREQUESTOR_CREATED Socket requestor created for application %1</term>
|
|
|
<listitem><para>
|
|
|
Debug message. A socket requesor (client of the socket creator) is created
|
|
|
for the corresponding application. Normally this should happen at most
|
|
@@ -4706,6 +4829,21 @@ be hidden, as it has higher debug level.
|
|
|
</para></listitem>
|
|
|
</varlistentry>
|
|
|
|
|
|
+<varlistentry id="SRVCOMM_EXCEPTION_ALLOC">
|
|
|
+<term>SRVCOMM_EXCEPTION_ALLOC exception when allocating a socket: %1</term>
|
|
|
+<listitem><para>
|
|
|
+The process tried to allocate a socket using the socket creator, but an error
|
|
|
+occurred. But it is not one of the errors we are sure are "safe". In this case
|
|
|
+it is unclear if the unsuccessful communication left the process and the bind10
|
|
|
+process in inconsistent state, so the process is going to abort to prevent
|
|
|
+further problems in that area.
|
|
|
+</para><para>
|
|
|
+This is probably a bug in the code, but it could be caused by other unusual
|
|
|
+conditions (like insufficient memory, deleted socket file used for
|
|
|
+communication).
|
|
|
+</para></listitem>
|
|
|
+</varlistentry>
|
|
|
+
|
|
|
<varlistentry id="SRVCOMM_KEYS_DEINIT">
|
|
|
<term>SRVCOMM_KEYS_DEINIT deinitializing TSIG keyring</term>
|
|
|
<listitem><para>
|
|
@@ -4745,6 +4883,15 @@ different set of IP addresses and ports than before.
|
|
|
</para></listitem>
|
|
|
</varlistentry>
|
|
|
|
|
|
+<varlistentry id="SRVCOMM_UNKNOWN_EXCEPTION_ALLOC">
|
|
|
+<term>SRVCOMM_UNKNOWN_EXCEPTION_ALLOC unknown exception when allocating a socket</term>
|
|
|
+<listitem><para>
|
|
|
+The situation is the same as in the SRVCOMM_EXCEPTION_ALLOC case, but further
|
|
|
+details about the error are unknown, because it was signaled by throwing
|
|
|
+something not being an exception. This is definitely a bug.
|
|
|
+</para></listitem>
|
|
|
+</varlistentry>
|
|
|
+
|
|
|
<varlistentry id="STATHTTPD_BAD_OPTION_VALUE">
|
|
|
<term>STATHTTPD_BAD_OPTION_VALUE bad command line argument: %1</term>
|
|
|
<listitem><para>
|