Typo police.

Partially obtained from: NetBSD PR# 3333
This commit is contained in:
Mike Pritchard 1997-03-16 07:12:20 +00:00
parent f9380a619e
commit 4b0eb76dc9
Notes: svn2git 2020-12-20 02:59:44 +00:00
svn path=/head/; revision=23929
2 changed files with 6 additions and 6 deletions

View File

@ -53,14 +53,14 @@ Options and operands available for
The
.Fl d
option causes debugging information to be written to syslog, recording
all RPC transations to the daemon. These messages are logged with level
all RPC transactions to the daemon. These messages are logged with level
LOG_DEBUG and facility LOG_DAEMON. If debug_level is not specified,
level 1 is assumed, giving one log line per protocol operation. Higher
debug levels can be specified, causing display of operation arguments
and internal operations of the daemon.
.El
.Pp
Error conditions are logged to syslog, irrespecive of the debug level,
Error conditions are logged to syslog, irrespective of the debug level,
using log level LOG_ERR and facility LOG_DAEMON.
.Pp
The

View File

@ -42,7 +42,7 @@
.Nm rpc.statd
.Op Fl d
.Sh DESCRIPTION
.Nm rpc.rstatd
.Nm rpc.statd
is a daemon which co-operates with rpc.statd daemons on other hosts to provide
a status monitoring service. The daemon accepts requests from
programs running on the local host (typically,
@ -63,13 +63,13 @@ Options and operands available for
The
.Fl d
option causes debugging information to be written to syslog, recording
all RPC transations to the daemon. These messages are logged with level
all RPC transactions to the daemon. These messages are logged with level
LOG_DEBUG and facility LOG_DAEMON. Error conditions are logged irrespective
of this option, using level LOG_ERR.
.El
.Pp
The
.Nm rpc.rstatd
.Nm rpc.statd
daemon must NOT be invoked by
.Xr inetd 8
because the protocol assumes that the daemon will run from system start time.
@ -89,7 +89,7 @@ RPC protocol specification used by local applications to register monitoring req
.Xr rpc.lockd 8
.Sh BUGS
There is no means for the daemon to tell when a monitored host has
disappeared permanently (eg. catastrophic harware failure), as opposed
disappeared permanently (eg. catastrophic hardware failure), as opposed
to transient failure of the host or an intermediate router. At present,
it will re-try notification attempts at frequent intervals for 10 minutes,
then hourly, and finally gives up after 24 hours.