statd - Unix, Linux Command


previous next AddThis Social Bookmark Button

NAME

rpc.statd - NSM status monitor

SYNOPSIS

/sbin/rpc.statd [-F] [-d] [-?] [-n name ] [-o port ] [-p port ] [-H prog ] [-V]

DESCRIPTION

The rpc.statd server implements the NSM (Network Status Monitor) RPC protocol. This service is somewhat misnamed, since it doesn’t actually provide active monitoring as one might suspect; instead, NSM implements a reboot notification service. It is used by the NFS file locking service, rpc.lockd, to implement lock recovery when the NFS server machine crashes and reboots.

Operation

For each NFS client or server machine to be monitored, rpc.statd creates a file in /var/lib/nfs/statd/sm. When starting, it iterates through these files and notifies the peer rpc.statd on those machines.

OPTIONS

TagDescription
-F By default, rpc.statd forks and puts itself in the background when started. The -F argument tells it to remain in the foreground. This option is mainly for debugging purposes.
-d By default, rpc.statd sends logging messages via syslog(3) to system log. The -d argument forces it to log verbose output to stderr instead. This option is mainly for debugging purposes, and may only be used in conjunction with the -F parameter.
-n, --name name
  specify a name for rpc.statd to use as the local hostname. By default, rpc.statd will call gethostname(2) to get the local hostname. Specifying a local hostname may be useful for machines with more than one interfaces.
-o, --outgoing-port port
  specify a port for rpc.statd to send outgoing status requests from. By default, rpc.statd will ask portmap(8) to assign it a port number. As of this writing, there is not a standard port number that portmap always or usually assigns. Specifying a port may be useful when implementing a firewall.
-p, --port port
  specify a port for rpc.statd to listen on. By default, rpc.statd will ask portmap(8) to assign it a port number. As of this writing, there is not a standard port number that portmap always or usually assigns. Specifying a port may be useful when implementing a firewall.
-P, --state-directory-path directory
  specify a directory in which to place statd state information. If this option is not specified the default of /var/lib/nfs is used.
-N Causes statd to run in the notify-only mode. When started in this mode, the statd program will check its state directory, send notifications to any monitored nodes, and exit once the notifications have been sent. This mode is used to enable Highly Available NFS implementations (i.e. HA-NFS).
-H, --ha-callout prog
  Specify a high availability callout program, which will receive callouts for all client monitor and unmonitor requests. This allows rpc.statd to be used in a High Availability NFS (HA-NFS) environment. The program will be run with 3 arguments: The first is either add-client or del-client depending on the reason for the callout. The second will be the name of the client. The third will be the name of the server as known to the client.
-? Causes rpc.statd to print out command-line help and exit.
-V Causes rpc.statd to print out version information and exit.

TCP_WRAPPERS SUPPORT

This rpc.statd version is protected by the tcp_wrapper library. You have to give the clients access to rpc.statd if they should be allowed to use it. To allow connects from clients of the .bar.com domain you could use the following line in /etc/hosts.allow:

statd: .bar.com

You have to use the daemon name statd for the daemon name (even if the binary has a different name).

For further information please have a look at the tcpd(8) and hosts_access(5) manual pages.

SIGNALS

SIGUSR1 causes rpc.statd to re-read the notify list from disk and send notifications to clients. This can be used in High Availability NFS (HA-NFS) environments to notify clients to reacquire file locks upon takeover of an NFS export from another server.

FILES

/var/lib/nfs/statd/sm/state
/var/lib/nfs/statd/sm/*
/var/lib/nfs/statd/sm.bak/*

SEE ALSO

Jeff Uphoff <juphoff@users.sourceforge.net>
Olaf Kirch <okir@monad.swb.de>
H.J. Lu <hjl@gnu.org>
Lon Hohberger <hohberger@missioncriticallinux.com>
Paul Clements <paul.clements@steeleye.com>
previous next Printer Friendly


  

Advertisements



Advertisements