Commit ae5693b8 authored by Jeremy C. Reed's avatar Jeremy C. Reed
Browse files

[master] lots of minor doc fixes in mes files

misspellings or typos

spelled out "wg" so next spell check doesn't fail on it

periods at end of sentences (even for incomplete bullet items
to be consistent)

remove double words (the the, up up)

This was not reviewed, but is mostly minor changes.
Two items I was unclear about I confirmed on jabber.
parent 778e6009
......@@ -141,7 +141,7 @@ The specific problem is printed in the log message.
The thread for maintaining data source clients has received a command to
reconfigure, and has now started this process.
% AUTH_DATASRC_CLIENTS_BUILDER_RECONFIGURE_SUCCESS data source reconfiguration completed succesfully
% AUTH_DATASRC_CLIENTS_BUILDER_RECONFIGURE_SUCCESS data source reconfiguration completed successfully
The thread for maintaining data source clients has finished reconfiguring
the data source clients, and is now running with the new configuration.
......@@ -169,7 +169,7 @@ probably better to stop and restart it.
% AUTH_DATA_SOURCE data source database file: %1
This is a debug message produced by the authoritative server when it accesses a
datebase data source, listing the file that is being accessed.
database data source, listing the file that is being accessed.
% AUTH_DNS_SERVICES_CREATED DNS services created
This is a debug message indicating that the component that will handling
......@@ -184,7 +184,7 @@ reason for the failure is given in the message.) The server will drop the
packet.
% AUTH_INVALID_STATISTICS_DATA invalid specification of statistics data specified
An error was encountered when the authoritiative server specified
An error was encountered when the authoritative server specified
statistics data which is invalid for the auth specification file.
% AUTH_LOAD_TSIG loading TSIG keys
......@@ -208,7 +208,7 @@ 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
coming too fast and the recipient 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
......
......@@ -154,7 +154,7 @@ 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
from its local configuration of components to run. This is an unusual
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
......@@ -262,7 +262,7 @@ indicated OS API function with given error.
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
Debug message given when BIND 10 has successfully started the object that
handles configuration and commands.
% BIND10_STARTED_PROCESS started %1
......
......@@ -53,7 +53,7 @@ inconsistent state, and it is advised to restore it from the backup that was
created when b10-dbutil started.
% DBUTIL_EXECUTE Executing SQL statement: %1
Debug message; the given SQL statement is executed
Debug message; the given SQL statement is executed.
% DBUTIL_FILE Database file: %1
The database file that is being checked.
......@@ -67,7 +67,7 @@ The given database statement failed to execute. The error is shown in the
message.
% DBUTIL_TOO_MANY_ARGUMENTS too many arguments to the command, maximum of one expected
There were too many command-line arguments to b10-dbutil
There were too many command-line arguments to b10-dbutil.
% DBUTIL_UPGRADE_CANCELED upgrade canceled; database has not been changed
The user aborted the upgrade, and b10-dbutil will now exit.
......@@ -95,7 +95,7 @@ again.
% DBUTIL_UPGRADE_PREPARATION_FAILED upgrade preparation failed: %1
An unexpected error occurred while b10-dbutil was preparing to upgrade the
database schema. The error is shown in the message
database schema. The error is shown in the message.
% DBUTIL_UPGRADE_SUCCESFUL database upgrade successfully completed
The database schema update was completed successfully.
......
......@@ -75,7 +75,7 @@ may well be a valid DHCP packet, just a type not expected by the server
% DHCP4_PACKET_RECEIVE_FAIL error on attempt to receive packet: %1
The IPv4 DHCP server tried to receive a packet but an error
occured during this attempt. The reason for the error is included in
occurred during this attempt. The reason for the error is included in
the message.
% DHCP4_PACKET_SEND_FAIL failed to send DHCPv4 packet: %1
......
......@@ -79,7 +79,7 @@ such failure. Each specific failure is logged in a separate log entry.
% DHCP6_LEASE_ALLOC lease %1 has been allocated (client duid=%2, iaid=%3)
This debug message indicates that the server successfully granted (in
response to client's REQUEST message) a lease. This is a normal behavior
and incicates successful operation.
and indicates successful operation.
% DHCP6_LEASE_ALLOC_FAIL failed to grant a lease for client duid=%1, iaid=%2
This message indicates that the server failed to grant (in response to
......@@ -121,7 +121,7 @@ a received OFFER packet as UNKNOWN).
% DHCP6_PACKET_RECEIVE_FAIL error on attempt to receive packet: %1
The IPv6 DHCP server tried to receive a packet but an error
occured during this attempt. The reason for the error is included in
occurred during this attempt. The reason for the error is included in
the message.
% DHCP6_PACKET_SEND_FAIL failed to send DHCPv6 packet: %1
......
......@@ -24,7 +24,7 @@ The serial fields of the first and last SOAs of AXFR (including AXFR-style
IXFR) are not the same. According to RFC 5936 these two SOAs must be the
"same" (not only for the serial), but it is still not clear what the
receiver should do if this condition does not hold. There was a discussion
about this at the IETF dnsext wg:
about this at the IETF dnsext working group:
http://www.ietf.org/mail-archive/web/dnsext/current/msg07908.html
and the general feeling seems that it would be better to reject the
transfer if a mismatch is detected. On the other hand, also as noted
......@@ -61,10 +61,10 @@ There was an error opening a connection to the master. The error is
shown in the log message.
% XFRIN_GOT_INCREMENTAL_RESP got incremental response for %1
In an attempt of IXFR processing, the begenning SOA of the first difference
In an attempt of IXFR processing, the beginning SOA of the first difference
(following the initial SOA that specified the final SOA for all the
differences) was found. This means a connection for xfrin tried IXFR
and really aot a response for incremental updates.
and really got a response for incremental updates.
% XFRIN_GOT_NONINCREMENTAL_RESP got nonincremental response for %1
Non incremental transfer was detected at the "first data" of a transfer,
......@@ -149,16 +149,16 @@ daemon will now shut down.
The AXFR transfer of the given zone was successful.
The provided information contains the following values:
messages: Number of overhead DNS messages in the transfer
messages: Number of overhead DNS messages in the transfer.
records: Number of Resource Records in the full transfer, excluding the
final SOA record that marks the end of the AXFR.
bytes: Full size of the transfer data on the wire.
run time: Time (in seconds) the complete axfr took
run time: Time (in seconds) the complete axfr took.
bytes/second: Transfer speed
bytes/second: Transfer speed.
% XFRIN_TSIG_KEY_NOT_FOUND TSIG key not found in key ring: %1
An attempt to start a transfer with TSIG was made, but the configured TSIG
......
......@@ -70,7 +70,7 @@ AXFR-style IXFR.
% XFROUT_IXFR_NO_ZONE IXFR client %1, %2: zone not found with journal
The requested zone in IXFR was not found in the data source
even though the xfrout daemon sucessfully found the SOA RR of the zone
even though the xfrout daemon successfully found the SOA RR of the zone
in the data source. This can happen if the administrator removed the
zone from the data source within the small duration between these
operations, but it's more likely to be a bug or broken data source.
......@@ -84,7 +84,7 @@ NOTAUTH.
An IXFR request was received, but the client's SOA version is the same as
or newer than that of the server. The xfrout server responds to the
request with the answer section being just one SOA of that version.
Note: as of this wrting the 'newer version' cannot be identified due to
Note: as of this writing the 'newer version' cannot be identified due to
the lack of support for the serial number arithmetic. This will soon
be implemented.
......@@ -206,7 +206,7 @@ xfrout daemon process is still running. This xfrout daemon (the one
printing this message) will not start.
% XFROUT_XFR_TRANSFER_CHECK_ERROR %1 client %2: check for transfer of %3 failed: %4
Pre-response check for an incomding XFR request failed unexpectedly.
Pre-response check for an incoming XFR request failed unexpectedly.
The most likely cause of this is that some low level error in the data
source, but it may also be other general (more unlikely) errors such
as memory shortage. Some detail of the error is also included in the
......
......@@ -97,7 +97,7 @@ There may be several reasons why this message may appear:
- The message ID has been mis-spelled in the local message file.
- The program outputting the message may not use that particular message
(e.g. it originates in a module not used by the program.)
(e.g. it originates in a module not used by the program).
- The local file was written for an earlier version of the BIND 10 software
and the later version no longer generates that message.
......@@ -131,7 +131,7 @@ version of BIND 10.
% LOG_READING_LOCAL_FILE reading local message file %1
This is an informational message output by BIND 10 when it starts to read
a local message file. (A local message file may replace the text of
one of more messages; the ID of the message will not be changed though.)
one or more messages; the ID of the message will not be changed though.)
% LOG_READ_ERROR error reading from message file %1: %2
The specified error was encountered reading from the named message file.
......
......@@ -122,7 +122,7 @@ as the class in the Zone Section, ANY, or NONE.
A FORMERR response is sent back to the client.
% LIBDDNS_UPDATE_DATASRC_ERROR error in datasource during DDNS update: %1
An error occured while committing the DDNS update changes to the
An error occurred while committing the DDNS update changes to the
datasource. The specific error is printed. A SERVFAIL response is sent
back to the client.
......
......@@ -86,7 +86,7 @@ SERVFAIL will be returned.
% RESLIB_NOTSINGLE_RESPONSE response to query for <%1> was not a response
A debug message, the response to the specified query from an upstream
nameserver was a CNAME that had mutiple RRs in the RRset. This is
nameserver was a CNAME that had multiple RRs in the RRset. This is
an invalid response according to the standards so a SERVFAIL will be
returned to the system making the original query.
......@@ -138,7 +138,7 @@ A debug message, the response to the specified query indicated an error
that is not covered by a specific code path. A SERVFAIL will be returned.
% RESLIB_RECQ_CACHE_FIND found <%1> in the cache (resolve() instance %2)
This is a debug message and indicates that a RecursiveQuery object found the
This is a debug message and indicates that a RecursiveQuery object found
the specified <name, class, type> tuple in the cache. The instance number
at the end of the message indicates which of the two resolve() methods has
been called.
......@@ -178,7 +178,7 @@ A debug message giving the round-trip time of the last query and response.
This is a debug message and indicates that a RunningQuery object found
the specified <name, class, type> tuple in the cache.
% RESLIB_RUNQ_CACHE_LOOKUP looking up up <%1> in the cache
% RESLIB_RUNQ_CACHE_LOOKUP looking up <%1> in the cache
This is a debug message and indicates that a RunningQuery object has made
a call to its doLookup() method to look up the specified <name, class, type>
tuple, the first action of which will be to examine the cache.
......
......@@ -17,11 +17,11 @@ $NAMESPACE isc::server_common
# \brief Messages for the server_common library
% SOCKETREQUESTOR_CREATED Socket requestor created for application %1
Debug message. A socket requesor (client of the socket creator) is created
Debug message. A socket requestor (client of the socket creator) is created
for the corresponding application. Normally this should happen at most
one time throughout the lifetime of the application.
% SOCKETREQUESTOR_DESTROYED Socket requestor destoryed
% SOCKETREQUESTOR_DESTROYED Socket requestor destroyed
Debug message. The socket requestor created at SOCKETREQUESTOR_CREATED
has been destroyed. This event is generally unexpected other than in
test cases.
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment