2 .\" Copyright 2014 Nexenta Systems, Inc. All rights reserved.
3 .\" Copyright (c) 1999, Sun Microsystems, Inc.
4 .\" All Rights Reserved.
5 .\" The contents of this file are subject to the terms of the Common Development and Distribution License (the "License"). You may not use this file except in compliance with the License.
6 .\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing. See the License for the specific language governing permissions and limitations under the License.
7 .\" When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE. If applicable, add the following below this CDDL HEADER, with the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner]
8 .TH NFSLOGD 1M "Nov 24, 2014"
10 nfslogd \- nfs logging daemon
14 \fB/usr/lib/nfs/nfslogd\fR
19 The \fBnfslogd\fR daemon provides operational logging to the Solaris \fBNFS\fR
20 server. It is the \fBnfslogd\fR daemon's job to generate the activity log by
21 analyzing the \fBRPC\fR operations processed by the \fBNFS\fR server. The log
22 will only be generated for file systems exported with logging enabled. This is
23 specified at file system export time by means of the \fBshare_nfs\fR(1M)
27 NFS server logging is not supported on Solaris machines that are using NFS
31 Each record in the log file includes a time stamp, the \fBIP\fR address (or
32 hostname if it can be resolved) of the client system, the file or directory
33 name the operation was performed on, and the type of operation. In the basic
34 format, the operation can either be an input (i) or output (o) operation. The
35 basic format of the \fBNFS\fR server log is compatible with the log format
36 generated by the Washington University \fBFTPd\fR daemon. The log format can be
37 extended to include directory modification operations, such as \fBmkdir\fR,
38 \fBrmdir\fR, and \fBremove\fR. The extended format is not compatible with the
39 Washington University \fBFTPd\fR daemon format. See \fBnfslog.conf\fR(4) for
43 The \fBNFS\fR server logging mechanism is divided in two phases. The first
44 phase is performed by the \fBNFS\fR kernel module, which records raw \fBRPC\fR
45 requests and their results in work buffers backed by permanent storage. The
46 location of the work buffers is specified in the /\fBetc/nfs/nfslog.conf\fR
47 file. Refer to \fBnfslog.conf\fR(4) for more information. The second phase
48 involves the \fBnfslogd\fR user-level daemon, which periodically reads the work
49 buffers, interprets the raw \fBRPC\fR information, groups related \fBRPC\fR
50 operations into single transaction records, and generates the output log. The
51 \fBnfslogd\fR daemon then sleeps waiting for more information to be logged to
52 the work buffers. The amount of time that the daemon sleeps can be configured
53 by modifying the \fBIDLE_TIME\fR parameter in \fB/etc/default/nfslogd\fR. The
54 work buffers are intended for internal consumption of the \fBnfslogd\fR daemon.
57 \fBNFS\fR operations use file handles as arguments instead of path names. For
58 this reason the \fBnfslogd\fR daemon needs to maintain a database of file
59 handle to path mappings in order to log the path name associated with an
60 operation instead of the corresponding file handle. A file handle entry is
61 added to the database when a client performs a lookup or other \fBNFS\fR
62 operation that returns a file handle to the client.
65 Once an \fBNFS\fR client obtains a file handle from a server, it can hold on to
66 it for an indefinite time, and later use it as an argument for an \fBNFS\fR
67 operation on the file or directory. The \fBNFS\fR client can use the file
68 handle even after the server reboots. Because the database needs to survive
69 server reboots, it is backed by permanent storage. The location of the database
70 is specified by the \fIfhtable\fR parameter in the \fB/etc/nfs/nfslog.conf\fR
71 file. This database is intended for the internal use of the \fBnfslogd\fR
75 In order to keep the size of the file handle mapping database manageable,
76 \fBnfslogd\fR prunes the database periodically. It removes file handle entries
77 that have not been accessed in more than a specified amount of time. The
78 \fBPRUNE_TIMEOUT\fR configurable parameter in \fB/etc/default/nfslogd\fR
79 specifies the interval length between successive runs of the pruning process.
80 A file handle record will be removed if it has not been used since the last
81 time the pruning process was executed. Pruning of the database can effectively
82 be disabled by setting the \fBPRUNE_TIMEOUT\fR as high as \fBINT_MAX\fR.
85 When pruning is enabled, there is always a risk that a client may have held on
86 to a file handle longer than the \fBPRUNE_TIMEOUT\fR and perform an \fBNFS\fR
87 operation on the file handle after the matching record in the mapping database
88 had been removed. In such case, the pathname for the file handle will not be
89 resolved, and the log will include the file handle instead of the pathname.
92 There are various configurable parameters that affect the behavior of the
93 \fBnfslogd\fR daemon. These parameters are found in \fB/etc/default/nfslogd\fR
94 and are described below:
101 Sets the file mode for the log files, work buffer files and file handle mapping
108 \fB\fBMIN_PROCESSING_SIZE\fR\fR
111 Specifies the minimum size, in bytes, that the buffer file must reach before
112 processing the work information and writing to the log file. The value of
113 \fBMIN_PROCESSING_SIZE\fR must be between 1 and \fBulimit\fR.
119 \fB\fBIDLE_TIME\fR\fR
122 Specifies the amount of time, in seconds, the daemon should sleep while waiting
123 for more information to be placed in the buffer file. \fBIDLE_TIME\fR also
124 determines how often the configuration file will be reread. The value of
125 \fBIDLE_TIME\fR must be between 1 and \fBINT_MAX\fR.
131 \fB\fBMAX_LOGS_PRESERVE\fR\fR
134 The \fBnfslogd\fR periodically cycles its logs. \fBMAX_LOGS_PRESERVE\fR
135 specifies the maximum number of log files to save. When \fBMAX_LOGS_PRESERVE\fR
136 is reached, the oldest files will be overwritten as new log files are created.
137 These files will be saved with a numbered extension, beginning with
138 \fBfilename.0\fR. The oldest file will have the highest numbered extension up
139 to the value configured for \fBMAX_LOGS_PRESERVE\fR. The value of
140 \fBMAX_LOGS_PRESERVE\fR must be between 1 and \fBINT_MAX\fR.
146 \fB\fBCYCLE_FREQUENCY\fR\fR
149 Specifies how often, in hours, the log files are cycled. \fBCYCLE_FREQUENCY\fR
150 is used to insure that the log files do not get too large. The value of
151 \fBCYCLE_FREQUENCY\fR must be between 1 and \fBINT_MAX\fR.
157 \fB\fBMAPPING_UPDATE_INTERVAL\fR\fR
160 Specifies the time interval, in seconds, between updates of the records in the
161 file handle to path mapping tables. Instead of updating the \fBatime\fR of a
162 record each time that record is accessed, it is only updated if it has aged
163 based on this parameter. The record access time is used by the pruning routine
164 to determine whether the record should be removed from the database. The value
165 of this parameter must be between 1 and \fBINT_MAX\fR.
171 \fB\fBPRUNE_TIMEOUT\fR\fR
174 Specifies when a database record times out, in hours. If the time that elapsed
175 since the record was last accessed is greater than \fBPRUNE_TIMEOUT\fR then the
176 record can be pruned from the database. The default value for
177 \fBPRUNE_TIMEOUT\fR is 168 hours (7 days). The value of \fBPRUNE_TIMEOUT\fR
178 must be between 1 and \fBINT_MAX\fR.
183 The following exit values are returned:
190 Daemon started successfully.
199 Daemon failed to start.
205 \fB\fB/etc/nfs/nfslogtab\fR \fR
214 \fB\fB/etc/nfs/nfslog.conf\fR\fR
223 \fB\fB/etc/default/nfslogd\fR\fR
231 \fBshare_nfs\fR(1M), \fBnfslog.conf\fR(4), \fBattributes\fR(5)
237 The \fBnfslogd\fR service is managed by the service management facility,
238 \fBsmf\fR(5), under the service identifier:
249 Administrative actions on this service, such as enabling, disabling, or
250 requesting restart, can be performed using \fBsvcadm\fR(1M). The service's
251 status can be queried using the \fBsvcs\fR(1) command.