sin/samba-mirror
1
0
Fork 0
mirror of https://github.com/samba-team/samba.git synced 2025-03-08 04:58:40 +03:00
Code

Correction of spelling errors

Browse Source 
* continous -> continuous
* activete  -> activate

(thanks to lintian)

See https://bugzilla.samba.org/show_bug.cgi?id=6935

Signed-off-by: Michael Adam <obnox@samba.org>

(This used to be ctdb commit fb6987c2f747d6dbf9bb3899a480124d1c242a90)
This commit is contained in:
Mathieu Parent 2011-03-23 00:16:27 +01:00 committed by Michael Adam
parent 653c0901d7
commit a5a6140b7e
8 changed files with 14 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
ctdb/config/events.d/README
View File

@ -71,7 +71,7 @@ monitor
The interval can be configured using the MonitorInterval tunable
but defaults to 15 seconds.
This event is triggered by ctdb to continously monitor that all
This event is triggered by ctdb to continuously monitor that all
managed services are healthy.
When invoked, the event script will check that the service is healthy
and return 0 if so. If the service is not healthy the event script

4
ctdb/doc/ctdb.1
View File

@ -786,7 +786,7 @@ This command can be used to remove all content of a database\&.
.PP
In addition to the normal loggign to a log file, CTDBD also keeps a in\-memory ringbuffer containing the most recent log entries for all log levels (except DEBUG)\&.
.PP
This is useful since it allows for keeping continous logs to a file at a reasonable non\-verbose level, but shortly after an incident has occured, a much more detailed log can be pulled from memory\&. This can allow you to avoid having to reproduce an issue due to the on\-disk logs being of insufficient detail\&.
This is useful since it allows for keeping continuous logs to a file at a reasonable non\-verbose level, but shortly after an incident has occured, a much more detailed log can be pulled from memory\&. This can allow you to avoid having to reproduce an issue due to the on\-disk logs being of insufficient detail\&.
.PP
This command extracts all messages of level or lower log level from memory and prints it to the screen\&.
.SS "clearlog"
@ -909,7 +909,7 @@ This command will dump a clustered TDB database to the screen\&. This is a debug
This command will dump the content of database backup to the screen (similar to ctdb catdb)\&. This is a debugging command\&.
.SS "getmonmode"
.PP
This command returns the monutoring mode of a node\&. The monitoring mode is either ACTIVE or DISABLED\&. Normally a node will continously monitor that all other nodes that are expected are in fact connected and that they respond to commands\&.
This command returns the monutoring mode of a node\&. The monitoring mode is either ACTIVE or DISABLED\&. Normally a node will continuously monitor that all other nodes that are expected are in fact connected and that they respond to commands\&.
.PP
ACTIVE \- This is the normal mode\&. The node is actively monitoring all other nodes, both that the transport is connected and also that the node responds to commands\&. If a node becomes unavailable, it will be marked as DISCONNECTED and a recovery is initiated to restore the cluster\&.
.PP

4
ctdb/doc/ctdb.1.html
View File

@ -595,7 +595,7 @@ This is mainly useful for backing up persistent databases such as secrets.tdb an
CTDBD also keeps a in-memory ringbuffer containing the most recent
log entries for all log levels (except DEBUG).
</p><p>
This is useful since it allows for keeping continous logs to a file
This is useful since it allows for keeping continuous logs to a file
at a reasonable non-verbose level, but shortly after an incident has
occured, a much more detailed log can be pulled from memory. This
can allow you to avoid having to reproduce an issue due to the
@ -678,7 +678,7 @@ HEALTH: NO-HEALTHY-NODES - ERROR - Backup of corrupted TDB in '/var/ctdb/persist
This command will dump the content of database backup to the screen
(similar to ctdb catdb). This is a debugging command.
</p></div><div class="refsect2" title="getmonmode"><a name="id541247"></a><h3>getmonmode</h3><p>
This command returns the monutoring mode of a node. The monitoring mode is either ACTIVE or DISABLED. Normally a node will continously monitor that all other nodes that are expected are in fact connected and that they respond to commands.
This command returns the monutoring mode of a node. The monitoring mode is either ACTIVE or DISABLED. Normally a node will continuously monitor that all other nodes that are expected are in fact connected and that they respond to commands.
</p><p>
ACTIVE - This is the normal mode. The node is actively monitoring all other nodes, both that the transport is connected and also that the node responds to commands. If a node becomes unavailable, it will be marked as DISCONNECTED and a recovery is initiated to restore the cluster.
</p><p>

4
ctdb/doc/ctdb.1.xml
View File

@ -1050,7 +1050,7 @@ This is mainly useful for backing up persistent databases such as secrets.tdb an
CTDBD also keeps a in-memory ringbuffer containing the most recent
log entries for all log levels (except DEBUG).
</para><para>
This is useful since it allows for keeping continous logs to a file
This is useful since it allows for keeping continuous logs to a file
at a reasonable non-verbose level, but shortly after an incident has
occured, a much more detailed log can be pulled from memory. This
can allow you to avoid having to reproduce an issue due to the
@ -1181,7 +1181,7 @@ HEALTH: NO-HEALTHY-NODES - ERROR - Backup of corrupted TDB in '/var/ctdb/persist
<refsect2><title>getmonmode</title>
<para>
This command returns the monutoring mode of a node. The monitoring mode is either ACTIVE or DISABLED. Normally a node will continously monitor that all other nodes that are expected are in fact connected and that they respond to commands.
This command returns the monutoring mode of a node. The monitoring mode is either ACTIVE or DISABLED. Normally a node will continuously monitor that all other nodes that are expected are in fact connected and that they respond to commands.
</para>
<para>
ACTIVE - This is the normal mode. The node is actively monitoring all other nodes, both that the transport is connected and also that the node responds to commands. If a node becomes unavailable, it will be marked as DISCONNECTED and a recovery is initiated to restore the cluster.

4
ctdb/doc/ctdbd.1
View File

@ -191,7 +191,7 @@ Send all log messages to syslog instead of to the ctdb logfile\&.
.RS 4
In addition to the normal loggign to a log file, CTDBD also keeps a in\-memory ringbuffer containing the most recent log entries for all log levels (except DEBUG)\&.
.sp
This is useful since it allows for keeping continous logs to a file at a reasonable non\-verbose level, but shortly after an incident has occured, a much more detailed log can be pulled from memory\&. This can allow you to avoid having to reproduce an issue due to the on\-disk logs being of insufficient detail\&.
This is useful since it allows for keeping continuous logs to a file at a reasonable non\-verbose level, but shortly after an incident has occured, a much more detailed log can be pulled from memory\&. This can allow you to avoid having to reproduce an issue due to the on\-disk logs being of insufficient detail\&.
.sp
This in\-memory ringbuffer contains a fixed number of the most recent entries\&. This is settable at startup either through the \-\-log\-ringbuf\-size argument, or preferably by using CTDB_LOG_RINGBUF_SIZE in the sysconfig file\&.
.sp
@ -426,7 +426,7 @@ Note: you can use LVS and public addresses at the same time\&.
.PP
To activate LVS on a CTDB node you must specify CTDB_PUBLIC_INTERFACE and CTDB_LVS_PUBLIC_ADDRESS in /etc/sysconfig/ctdb\&.
.PP
You must also specify the "\-\-lvs" command line argument to ctdbd to activete LVS as a capability of the node\&. This should be done automatically for you by the /etc/init\&.d/ctdb script\&.
You must also specify the "\-\-lvs" command line argument to ctdbd to activate LVS as a capability of the node\&. This should be done automatically for you by the /etc/init\&.d/ctdb script\&.
.PP
Example:
.sp

4
ctdb/doc/ctdbd.1.html
View File

@ -131,7 +131,7 @@
CTDBD also keeps a in-memory ringbuffer containing the most recent
log entries for all log levels (except DEBUG).
</p><p>
This is useful since it allows for keeping continous logs to a file
This is useful since it allows for keeping continuous logs to a file
at a reasonable non-verbose level, but shortly after an incident has
occured, a much more detailed log can be pulled from memory. This
can allow you to avoid having to reproduce an issue due to the
@ -373,7 +373,7 @@ ctdb will try to reassign public IP addresses onto the new node as a way to dist
To activate LVS on a CTDB node you must specify CTDB_PUBLIC_INTERFACE and
CTDB_LVS_PUBLIC_ADDRESS in /etc/sysconfig/ctdb.
</p><p>
You must also specify the "--lvs" command line argument to ctdbd to activete LVS as a capability of the node. This should be done automatically for you by the /etc/init.d/ctdb script.
You must also specify the "--lvs" command line argument to ctdbd to activate LVS as a capability of the node. This should be done automatically for you by the /etc/init.d/ctdb script.
</p><p>
Example:
</p><pre class="screen">

4
ctdb/doc/ctdbd.1.xml
View File

@ -349,7 +349,7 @@
log entries for all log levels (except DEBUG).
</para>
<para>
This is useful since it allows for keeping continous logs to a file
This is useful since it allows for keeping continuous logs to a file
at a reasonable non-verbose level, but shortly after an incident has
occured, a much more detailed log can be pulled from memory. This
can allow you to avoid having to reproduce an issue due to the
@ -737,7 +737,7 @@ ctdb will try to reassign public IP addresses onto the new node as a way to dist
</para>
<para>
You must also specify the "--lvs" command line argument to ctdbd to activete LVS as a capability of the node. This should be done automatically for you by the /etc/init.d/ctdb script.
You must also specify the "--lvs" command line argument to ctdbd to activate LVS as a capability of the node. This should be done automatically for you by the /etc/init.d/ctdb script.
</para>
<para>

2
ctdb/server/ctdb_vacuum.c
View File

@ -874,7 +874,7 @@ static int update_tuning_db(struct ctdb_db_context *ctdb_db, struct vacuum_data
/*
* re-calc new vacuum interval:
* in case no limit was reached we continously increase the interval
* in case no limit was reached we continuously increase the interval
* until vacuum_max_interval is reached
* in case a limit was reached we divide the current interval by 2
* unless vacuum_min_interval is reached