mirror of https://github.com/mkerrisk/man-pages
acct.5, elf.5, hosts.5, resolv.conf.5, rpc.5, slabinfo.5, utmp.5: Formatting fix: replace blank lines with .PP/.IP
Blank lines shouldn't generally appear in *roff source (other than in code examples), since they create large vertical spaces between text blocks. Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This commit is contained in:
Michael Kerrisk
parent
2a86152e72
commit
eabf3ae555
12
man5/acct.5
12
man5/acct.5
|
|
@ -33,18 +33,18 @@ If the kernel is built with the process accounting option enabled
|
|||
then calling
|
||||
.BR acct (2)
|
||||
starts process accounting, for example:
|
||||
|
||||
.PP
|
||||
.in +4n
|
||||
acct("/var/log/pacct");
|
||||
.in
|
||||
|
||||
.PP
|
||||
When process accounting is enabled, the kernel writes a record
|
||||
to the accounting file as each process on the system terminates.
|
||||
This record contains information about the terminated process,
|
||||
and is defined in
|
||||
.I <sys/acct.h>
|
||||
as follows:
|
||||
|
||||
.PP
|
||||
.in +4n
|
||||
.nf
|
||||
#define ACCT_COMM 16
|
||||
|
|
@ -119,7 +119,7 @@ and
|
|||
fields is widened from 16 to 32 bits
|
||||
(in line with the increased size of UID and GIDs in Linux 2.4 and later).
|
||||
The records are defined as follows:
|
||||
|
||||
.PP
|
||||
.in +4n
|
||||
.nf
|
||||
struct acct_v3 {
|
||||
|
|
@ -157,14 +157,14 @@ and the details vary somewhat between systems.
|
|||
.SH NOTES
|
||||
Records in the accounting file are ordered by termination time of
|
||||
the process.
|
||||
|
||||
.PP
|
||||
In kernels up to and including 2.6.9,
|
||||
a separate accounting record is written for each thread created using
|
||||
the NPTL threading library;
|
||||
since Linux 2.6.10,
|
||||
a single accounting record is written for the entire process
|
||||
on termination of the last thread in the process.
|
||||
|
||||
.PP
|
||||
The
|
||||
.I proc/sys/kernel/acct
|
||||
file, described in
|
||||
|
|
|
|||
18
man5/elf.5
18
man5/elf.5
|
|
@ -238,10 +238,10 @@ Two's complement, big-endian.
|
|||
.PD
|
||||
.RE
|
||||
.TP
|
||||
.PD 0
|
||||
.BR EI_VERSION
|
||||
The seventh byte is the version number of the ELF specification:
|
||||
|
||||
.IP
|
||||
.PD 0
|
||||
.RS
|
||||
.TP 14
|
||||
.BR EV_NONE
|
||||
|
|
@ -1852,7 +1852,7 @@ but many projects define their own set of extensions.
|
|||
For example,
|
||||
the GNU tool chain uses ELF notes to pass information from
|
||||
the linker to the C library.
|
||||
|
||||
.PP
|
||||
Note sections contain a series of notes (see the
|
||||
.I struct
|
||||
definitions below).
|
||||
|
|
@ -1860,10 +1860,10 @@ Each note is followed by the name field (whose length is defined in
|
|||
\fIn_namesz\fR) and then by the descriptor field (whose length is defined in
|
||||
\fIn_descsz\fR) and whose starting address has a 4 byte alignment.
|
||||
Neither field is defined in the note struct due to their arbitrary lengths.
|
||||
|
||||
.PP
|
||||
An example for parsing out two consecutive notes should clarify their layout
|
||||
in memory:
|
||||
|
||||
.PP
|
||||
.in +4n
|
||||
.nf
|
||||
void *memory, *name, *desc;
|
||||
|
|
@ -1887,7 +1887,7 @@ next_note = memory + sizeof(*note) +
|
|||
ALIGN_UP(note->n_descsz, 4);
|
||||
.fi
|
||||
.in
|
||||
|
||||
.PP
|
||||
Keep in mind that the interpretation of
|
||||
.I n_type
|
||||
depends on the namespace defined by the
|
||||
|
|
@ -2073,7 +2073,7 @@ Extensions used by the GNU tool chain.
|
|||
.B NT_GNU_ABI_TAG
|
||||
Operating system (OS) ABI information.
|
||||
The desc field will be 4 words:
|
||||
|
||||
.IP
|
||||
.PD 0
|
||||
.RS
|
||||
.IP \(bu 2
|
||||
|
|
@ -2091,7 +2091,7 @@ word 3: subminor version of the ABI
|
|||
.B NT_GNU_HWCAP
|
||||
Synthetic hwcap information.
|
||||
The desc field begins with two words:
|
||||
|
||||
.IP
|
||||
.PD 0
|
||||
.RS
|
||||
.IP \(bu 2
|
||||
|
|
@ -2130,7 +2130,7 @@ A version string of some sort.
|
|||
Architecture information.
|
||||
.PD
|
||||
.RE
|
||||
|
||||
.PP
|
||||
.RE
|
||||
.SH NOTES
|
||||
.\" OpenBSD
|
||||
|
|
|
|||
|
|
@ -91,7 +91,7 @@ except in cases where the file is cached by applications.
|
|||
.SS Historical notes
|
||||
RFC\ 952 gave the original format for the host table, though it has
|
||||
since changed.
|
||||
|
||||
.PP
|
||||
Before the advent of DNS, the host table was the only way of resolving
|
||||
hostnames on the fledgling Internet.
|
||||
Indeed, this file could be
|
||||
|
|
@ -129,7 +129,7 @@ ff02::2 ip6-allrouters
|
|||
.BR resolver (5),
|
||||
.BR hostname (7),
|
||||
.BR named (8)
|
||||
|
||||
.PP
|
||||
Internet RFC\ 952
|
||||
.\" .SH AUTHOR
|
||||
.\" This manual page was written by Manoj Srivastava <srivasta@debian.org>,
|
||||
|
|
|
|||
|
|
@ -119,7 +119,7 @@ and optional network pairs are separated by slashes.
|
|||
Up to 10 pairs may
|
||||
be specified.
|
||||
Here is an example:
|
||||
|
||||
.IP
|
||||
.in +4n
|
||||
sortlist 130.155.160.0/255.255.240.0 130.155.0.0
|
||||
.in
|
||||
|
|
@ -323,7 +323,7 @@ as explained above under \fBoptions\fP.
|
|||
The keyword and value must appear on a single line, and the keyword
|
||||
(e.g., \fBnameserver\fP) must start the line.
|
||||
The value follows the keyword, separated by white space.
|
||||
|
||||
.PP
|
||||
Lines that contain a semicolon (;) or hash character (#)
|
||||
in the first column are treated as comments.
|
||||
.SH FILES
|
||||
|
|
@ -337,5 +337,5 @@ in the first column are treated as comments.
|
|||
.BR nsswitch.conf (5),
|
||||
.BR hostname (7),
|
||||
.BR named (8)
|
||||
|
||||
.PP
|
||||
Name Server Operations Guide for BIND
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ The
|
|||
file contains user readable names that
|
||||
can be used in place of RPC program numbers.
|
||||
Each line has the following information:
|
||||
|
||||
.PP
|
||||
.PD 0
|
||||
.IP \(bu 3
|
||||
name of server for the RPC program
|
||||
|
|
|
|||
|
|
@ -55,7 +55,7 @@ which allows an application that is reading the file to handle changes
|
|||
in the file format.
|
||||
(See VERSIONS, below.)
|
||||
The next line lists the names of the columns in the remaining lines.
|
||||
|
||||
.PP
|
||||
Each of the remaining lines displays information about a specified cache.
|
||||
Following the cache name,
|
||||
the output shown in each line shows three components for each cache:
|
||||
|
|
@ -94,9 +94,9 @@ When using the older SLAB allocator,
|
|||
the tunables for a particular cache can be set by writing
|
||||
lines of the following form to
|
||||
.IR /proc/slabinfo :
|
||||
|
||||
.PP
|
||||
# \fBecho 'name limit batchcount sharedfactor' > /proc/slabinfo\fP
|
||||
|
||||
.PP
|
||||
Here,
|
||||
.I name
|
||||
is the cache name, and
|
||||
|
|
@ -116,7 +116,7 @@ and
|
|||
should be nonnegative.
|
||||
If any of the specified values is invalid,
|
||||
the cache settings are left unchanged.
|
||||
|
||||
.PP
|
||||
The
|
||||
.I tunables
|
||||
entries in each line contain the following fields:
|
||||
|
|
@ -155,7 +155,7 @@ Note that because of object alignment and slab cache overhead,
|
|||
objects are not normally packed tightly into pages.
|
||||
Pages with even one in-use object are considered in-use and cannot be
|
||||
freed.
|
||||
|
||||
.PP
|
||||
Kernels configured with
|
||||
.B CONFIG_DEBUG_SLAB
|
||||
will also have additional statistics fields in each line,
|
||||
|
|
@ -222,14 +222,14 @@ Only root can read and (if the kernel was configured with
|
|||
write the
|
||||
.IR /proc/slabinfo
|
||||
file.
|
||||
|
||||
.PP
|
||||
The total amount of memory allocated to the SLAB/SLUB cache is shown in the
|
||||
.I Slab
|
||||
field of
|
||||
.IR /proc/meminfo .
|
||||
.SH SEE ALSO
|
||||
.BR slabtop (1)
|
||||
|
||||
.PP
|
||||
The kernel source file
|
||||
.IR Documentation/vm/slub.txt
|
||||
and
|
||||
|
|
|
|||
|
|
@ -244,7 +244,7 @@ POSIX.1 does not specify the lengths of the
|
|||
and
|
||||
.I ut_user
|
||||
fields.
|
||||
|
||||
.PP
|
||||
Linux defines the
|
||||
.I utmpx
|
||||
structure to be the same as the
|
||||
|
|
@ -253,14 +253,14 @@ structure.
|
|||
.SS Comparison with historical systems
|
||||
Linux utmp entries conform neither to v7/BSD nor to System V; they are a
|
||||
mix of the two.
|
||||
|
||||
.PP
|
||||
v7/BSD has fewer fields; most importantly it lacks
|
||||
\fIut_type\fP, which causes native v7/BSD-like programs to display (for
|
||||
example) dead or login entries.
|
||||
Further, there is no configuration file
|
||||
which allocates slots to sessions.
|
||||
BSD does so because it lacks \fIut_id\fP fields.
|
||||
|
||||
.PP
|
||||
In Linux (as in System V), the \fIut_id\fP field of a
|
||||
record will never change once it has been set, which reserves that slot
|
||||
without needing a configuration file.
|
||||
|
|
@ -315,7 +315,7 @@ then instead of the call:
|
|||
gettimeofday((struct timeval *) &ut.ut_tv, NULL);
|
||||
.fi
|
||||
.in
|
||||
|
||||
.PP
|
||||
the following method of setting this field is recommended:
|
||||
.in +4n
|
||||
.nf
|
||||
|
|
|
|||
Loading…
Reference in New Issue