title: lmbench_bw_mem(8)

summary: time memory bandwidth

text:
# lmbench_bw_mem(8)

## NAME
bw_mem - time memory bandwidth

## SYNOPSIS
bw_mem_cp [ -P <parallelism> ] [ -W <warmups> ] [ -N <repetitions> ] size rd|wr|rdwr|cp|fwr|frd|bzero|bcopy [align]

## DESCRIPTION
bw_mem allocates twice the specified amount of memory, zeros it, and then times the copying of the first half to the second half. Results are reported in megabytes moved per second.

The size specification may end with ``k'' or ``m'' to mean kilobytes (* 1024) or megabytes (* 1024 * 1024).

## OUTPUT
Output format is "%0.2f %.2f\n", megabytes, megabytes_per_second, i.e.,

8.00 25.33

There are nine different memory benchmarks in bw_mem. They each measure slightly different methods for reading, writing or copying data.

rd

measures the time to read data into the processor. It computes the sum of an array of integer values. It accesses every fourth word.

wr

measures the time to write data to memory. It assigns a constant value to each memory of an array of integer values. It accesses every fourth word.

rdwr

measures the time to read data into memory and then write data to the same memory location. For each element in an array it adds the current value to a running sum before assigning a new (constant) value to the element. It accesses every fourth word.

cp

measures the time to copy data from one location to another. It does an array copy: dest[i] = source[i]. It accesses every fourth word.

frd

measures the time to read data into the processor. It computes the sum of an array of integer values.

fwr

measures the time to write data to memory. It assigns a constant value to each memory of an array of integer values.

fcp

measures the time to copy data from one location to another. It does an array copy: dest[i] = source[i].

bzero

measures how fast the system can bzero memory.

bcopy

measures how fast the system can bcopy data.

## MEMORY UTILIZATION
This benchmark can move up to three times the requested memory. Bcopy will use 2-3 times as much memory bandwidth: there is one read from the source and a write to the destionation. The write usually results in a cache line read and then a write back of the cache line at some later point. Memory utilization might be reduced by 1/3 if the processor architecture implemented ``load cache line'' and ``store cache line'' instructions (as well as ``getcachelinesize'').

## SEE ALSO
lmbench(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


package: lmbench

title: lmbench_bw_mem_rd(8)

summary: time memory read rate (with overhead)

text:
# lmbench_bw_mem_rd(8)

## NAME
bw_mem_rd - time memory read rate (with overhead)

## SYNOPSIS
bw_mem_rd size

## DESCRIPTION
bw_mem_rd allocates the specified amount of memory, zeros it, and then times the reading of that memory as a series of integer loads and adds. Each four byte integer is loaded and added to accumulator.

The size specification may end with ``k'' or ``m'' to mean kilobytes (* 1024) or megabytes (* 1024 * 1024).

## OUTPUT
Output format is "%0.2f %.2f\n", megabytes, megabytes_per_second, i.e.,

8.00 25.33

## MEMORY UTILIZATION
This benchmark should move approximately the reported amount of memory.

## ACKNOWLEDGEMENT
Funding for the development of this tool was provided by Sun Microsystems Computer Corporation.

## SEE ALSO
lmbench(8).

branch: sisyphus


title: lmbench_bw_mmap_rd(8)

summary: time the reading and summing of a file

text:
# lmbench_bw_mmap_rd(8)

## NAME
bw_mmap_rd - time the reading and summing of a file

## SYNOPSIS
bw_mmap_rd [ -P <parallelism> ] [ -W <warmups> ] [ -N <repetitions> ] size file

## DESCRIPTION
bw_mmap_rd creates a memory mapping to the file and then reads the mapping in an unrolled loop similar to that used in bw_mem_rd(8). The benchmark is intended to be used on a file that is in memory, i.e., the benchmark is a reread benchmark. Other file benchmarking can be done with lmdd(8).

The size specification may end with ``k'' or ``m'' to mean kilobytes (* 1024) or megabytes (* 1024 * 1024).

## OUTPUT
Output format is "%0.2f %.2f\n", megabytes, megabytes_per_second, i.e.,

8.00 25.33

## MEMORY UTILIZATION
This benchmark should move approximately the reported amount of memory.

## ACKNOWLEDGEMENT
Funding for the development of this tool was provided by Sun Microsystems Computer Corporation.

## SEE ALSO
lmbench(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


title: lmbench_bw_pipe(8)

summary: time data movement through pipes

text:
# lmbench_bw_pipe(8)

## NAME
bw_pipe - time data movement through pipes

## SYNOPSIS
bw_pipe [ -m <message size> ] [ -M <total bytes> ] [ -P <parallelism> ] [ -W <warmups> ] [ -N <repetitions> ]

## DESCRIPTION
bw_pipe creates a Unix pipe between two processes and moves total bytes through the pipe in message size chunks (note that pipes are typically sized smaller than that). The default total bytes is 10MB and the default message size is 64KB.

## OUTPUT
Output format is "Pipe bandwidth: %0.2f MB/sec\n", megabytes_per_second, i.e.,

Pipe bandwidth: 4.87 MB/sec

## MEMORY UTILIZATION
This benchmark can move up to six times the requested memory per process. There are two processes, the sender and the receiver. Most Unix systems implement the read/write system calls as a bcopy from/to kernel space to/from user space. Bcopy will use 2-3 times as much memory bandwidth: there is one read from the source and a write to the destionation. The write usually results in a cache line read and then a write back of the cache line at some later point. Memory utilization might be reduced by 1/3 if the processor architecture implemented "load cache line" and "store cache line" instructions (as well as getcachelinesize).

## ACKNOWLEDGEMENT
Funding for the development of this tool was provided by Sun Microsystems Computer Corporation.

## SEE ALSO
lmbench(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


title: lmbench_bw_tcp(8)

text:
# lmbench_bw_tcp(8)

## NAME
bw_tcp - time data movement through TCP/IP sockets

## SYNOPSIS
bw_tcp [ -m <message size> ] [ -M <total bytes> ] [ -P <parallelism> ] [ -W <warmups> ] [ -N <repetitions> ] server

bw_tcp -s

bw_tcp -S <server>

## DESCRIPTION
bw_tcp is a client/server program that moves data over a TCP/IP socket. Nothing is done with the data on either side; total bytes of data is moved in message size chunks.

bw_tcp has three forms of usage: as a server (-s), as a client (bw_tcp localhost), and as a shutdown (bw_tcp -S localhost).

The default amount of data is 10MB. The client form may specify a different amount of data. Specifications may end with ``k'' or ``m'' to mean kilobytes (* 1024) or megabytes (* 1024 * 1024).

## OUTPUT
Output format is Socket bandwidth using localhost: 2.32 MB/sec

## MEMORY UTILIZATION
This benchmark can move up to six times the requested memory per process when run through the loopback device. There are two processes, the sender and the receiver. Most Unix systems implement the read/write system calls as a bcopy from/to kernel space to/from user space. Bcopy will use 2-3 times as much memory bandwidth: there is one read from the source and a write to the destionation. The write usually results in a cache line read and then a write back of the cache line at some later point. Memory utilization might be reduced by 1/3 if the processor architecture implemented "load cache line" and "store cache line" instructions (as well as getcachelinesize).

## ACKNOWLEDGEMENT
Funding for the development of this tool was provided by Sun Microsystems Computer Corporation and Silicon Graphics, Inc.

## SEE ALSO
lmbench(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


title: lmbench_bw_unix(8)

summary: UNIX pipe bandwidth

text:
# lmbench_bw_unix(8)

## NAME
bw_unix - UNIX pipe bandwidth

## SYNOPSIS
bw_unix [ -P <parallelism> ] [ -W <warmups> ] [ -N <repetitions> ] size

## DESCRIPTION
bw_unix creates a pipe and forks a child process which keeps writing data to the pipe as fast as it can. The benchmark measures how fast the parent process can read the data in size-byte chunks from the pipe. Nothing is done with the data in either the parent (reader) or child (writer) processes.

The size specification may end with ``k'' or ``m'' to mean kilobytes (* 1024) or megabytes (* 1024 * 1024).

## OUTPUT
Output format is "%0.2f %.2f\n", megabytes, megabytes_per_second, i.e.,

8.00 25.33

## MEMORY UTILIZATION
This benchmark should move approximately the reported amount of memory.

## ACKNOWLEDGEMENT
Funding for the development of this tool was provided by Sun Microsystems Computer Corporation.

## SEE ALSO
lmbench(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


title: lmbench_cache(8)

summary: cache parameters

text:
# lmbench_cache(8)

## NAME
cache - cache parameters

## SYNOPSIS
cache [ -L <line size> ] [ -M <len> ] [ -W <warmups> ] [ -N <repetitions> ]

## DESCRIPTION
cache tries to determine the characteristics of the memory hierarchy. It attempts to determine the number of caches, the size of each cache, the line size for each cache, and the available memory parallelism at each level in the memory hierarchy. The largest amount of memory it will examine is len bytes.

cache first attempts to determine the number and size of caches by measuring the memory latency for various memory sizes. Once it has identified the various caches it then measures the latency, parallelism, and line size for each cache. Unfortunately, determining the cache size merely from latency is exceedingly difficult due to variations in cache replacement and prefetching strategies.

## BUGS
cache is an experimental benchmark and is known to fail on many processors. In particular there are a large number of machines with weird caching behavior that confuse cache and prevent it from accurately determining the number and size of the various caches.

## SEE ALSO
lmbench(8), line(8), tlb(8), par_mem(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


title: lmbench_lat_connect(8)

text:
# lmbench_lat_connect(8)

## NAME
lat_connect - measure interprocess connection latency via TCP/IP

## SYNOPSIS
lat_connect -s

lat_connect [ -P <parallelism> ] [ -W <warmups> ] [ -N <repetitions> ] hostname

lat_connect -S hostname

## DESCRIPTION
lat_connect is a client/server program that measures interprocess connection latencies. The benchmark times the creation and connection of an AF_INET (aka TCP/IP) socket to a remote server. Care is take that the connection time does not include any other overhead, such as the gethostbyname() or remote port lookups since these add more overhead than the connection establishment itself.

lat_connect has three forms of usage: as a server (-s), as a client (lat_connect localhost), and as a shutdown (lat_connect -S localhost).

## OUTPUT
The reported time is in microseconds per connection. Output format is like so

TCP/IP connection cost to localhost: 1006 microseconds

## SEE ALSO
lmbench(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


title: lmbench_lat_ctx(8)

summary: context switching benchmark

text:
# lmbench_lat_ctx(8)

## NAME
lat_ctx - context switching benchmark

## SYNOPSIS
lat_ctx [ -P <parallelism> ] [ -W <warmups> ] [ -N <repetitions> ] [ -s <size_in_kbytes> ] #procs [ #procs ... ]

## DESCRIPTION
lat_ctx measures context switching time for any reasonable number of processes of any reasonable size. The processes are connected in a ring of Unix pipes. Each process reads a token from its pipe, possibly does some work, and then writes the token to the next process.

Processes may vary in number. Smaller numbers of processes result in faster context switches. More than 20 processes is not supported.

Processes may vary in size. A size of zero is the baseline process that does nothing except pass the token on to the next process. A process size of greater than zero means that the process does some work before passing on the token. The work is simulated as the summing up of an array of the specified size. The summing is an unrolled loop of about a 2.7 thousand instructions.

The effect is that both the data and the instruction cache get polluted by some amount before the token is passed on. The data cache gets polluted by approximately the process ``size''. The instruction cache gets polluted by a constant amount, approximately 2.7 thousand instructions.

The pollution of the caches results in larger context switching times for the larger processes. This may be confusing because the benchmark takes pains to measure only the context switch time, not including the overhead of doing the work. The subtle point is that the overhead is measured using hot caches. As the number and size of the processes increases, the caches are more and more polluted until the set of processes do not fit. The context switch times go up because a context switch is defined as the switch time plus the time it takes to restore all of the process state, including cache state. This means that the switch includes the time for the cache misses on larger processes.

## OUTPUT
Output format is intended as input to xgraph or some similar program. The format is multi line, the first line is a title that specifies the size and non-context switching overhead of the test. Each subsequent line is a pair of numbers that indicates the number of processes and the cost of a context switch. The overhead and the context switch times are in micro second units. The numbers below are for a SPARCstation 2.

```
"size=0 ovr=179
2 71
4 104
8 134
16 333
20 438
```

## BUGS
The numbers produced by this benchmark are somewhat inaccurate; they vary by about 10 to 15% from run to run. A series of runs may be done and the lowest numbers reported. The lower the number the more accurate the results.

The reasons for the inaccuracies are possibly interaction between the VM system and the processor caches. It is possible that sometimes the benchmark processes are laid out in memory such that there are fewer TLB/cache conflicts than other times. This is pure speculation on our part.

## ACKNOWLEDGEMENT
Funding for the development of this tool was provided by Sun Microsystems Computer Corporation.

## SEE ALSO
lmbench(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


title: lmbench_lat_fcntl(8)

summary: fcntl file locking benchmark

text:
# lmbench_lat_fcntl(8)

## NAME
lat_fcntl - fcntl file locking benchmark

## SYNOPSIS
lat_ctx [ -P <parallelism> ] [ -W <warmups> ] [ -N <repetitions> ]

## DESCRIPTION
lat_fcntl is a client/server program that measures file locking latencies. The benchmark alternately locks and unlocks files so that only one of the client or server is running at a time, similar to ``hot potato'' message passing benchmarks. No other work is done in the processes.

## ACKNOWLEDGEMENT
Funding for the development of this tool was provided by Sun Microsystems Computer Corporation.

## SEE ALSO
lmbench(8), lat_fifo(8), lat_tcp(8), lat_udp(8), lat_unix(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


title: lmbench_lat_fifo(8)

summary: FIFO benchmark

text:
# lmbench_lat_fifo(8)

## NAME
lat_fifo - FIFO benchmark

## SYNOPSIS
lat_ctx [ -P <parallelism> ] [ -W <warmups> ] [ -N <repetitions> ]

## DESCRIPTION
lat_fifo is a client/server program that measures interprocess communication latencies. The benchmark passes a message back and forth between the two processes (this sort of benchmark is frequently referred to as a ``hot potato'' benchmark). No other work is done in the processes. The message is passed back and forth using FIFOs.

## ACKNOWLEDGEMENT
Funding for the development of this tool was provided by Sun Microsystems Computer Corporation.

## SEE ALSO
lmbench(8), lat_fcntl(8), lat_tcp(8), lat_udp(8), lat_unix(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


title: lmbench_lat_fs(8)

text:
# lmbench_lat_fs(8)

## NAME
lat_fs - measure file system create/delete performance

## SYNOPSIS
lat_fs [ dir ]

## DESCRIPTION
lat_fs is a program that creates a number of small files in the current working directory and then removes the files. Both the creation and removal of the files is timed.

## OPTIONS
If dir is specified, lat_fs will change to that directory first and do the creates and deletes there. Otherwise the creates and deletes are done in $PWD.

## OUTPUT
The results are in terms of creates per second and deletes per second as a function of file size. The output is in 4 column form and is the size of the file, the number created, the creations per second, and the removals per second. Output format looks like:

```
0k      500     1304    2740
1k      500     904     1663
4k      500     861     1647
10k     500     674     1516
```

## SEE ALSO
lmbench(8).


title: lmbench_lat_http(8)

summary: fcntl file locking benchmark

text:
# lmbench_lat_http(8)

## NAME
lat_fcntl - fcntl file locking benchmark

## SYNOPSIS
lat_ctx [ -d ] [ -e ] [ -S ] serverhost [ port ]

## DESCRIPTION
lat_http is a client/server program that measures simple http transaction latencies. It has its own HTTP server, and it is meant to simply measure the minimum overall costs of simple HTTP ``GET'' transactions. It does not measure the performance of third-party HTTP servers.

The client simply makes a series of HTTP GET requests for files. The files are a fixed set of files included with the benchmark. No special care was made to ensure that the file sizes match and predetermined distribution.

## ACKNOWLEDGEMENT
Funding for the development of this tool was provided by Sun Microsystems Computer Corporation.

## SEE ALSO
lmbench(8), lat_connect(8), lat_tcp(8), lat_sig(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


title: lmbench_lat_mem_rd(8)

summary: memory read latency benchmark

text:
# lmbench_lat_mem_rd(8)

## NAME
lat_mem_rd - memory read latency benchmark

## SYNOPSIS
lat_mem_rd [ -P <parallelism> ] [ -W <warmups> ] [ -N <repetitions> ] size_in_megabytes stride [ stride stride... ]

## DESCRIPTION
lat_mem_rd measures memory read latency for varying memory sizes and strides. The results are reported in nanoseconds per load and have been verified accurate to within a few nanoseconds on an SGI Indy.

The entire memory hierarchy is measured, including onboard cache latency and size, external cache latency and size, main memory latency, and TLB miss latency.

Only data accesses are measured; the instruction cache is not measured.

The benchmark runs as two nested loops. The outer loop is the stride size. The inner loop is the array size. For each array size, the benchmark creates a ring of pointers that point backward one stride. Traversing the array is done by

p = (char **)*p;

in a for loop (the over head of the for loop is not significant; the loop is an unrolled loop 100 loads long).

The size of the array varies from 512 bytes to (typically) eight megabytes. For the small sizes, the cache will have an effect, and the loads will be much faster. This becomes much more apparent when the data is plotted.

Since this benchmark uses fixed-stride offsets in the pointer chain, it may be vulnerable to smart, stride-sensitive cache prefetching policies. Older machines were typically able to prefetch for sequential access patterns, and some were able to prefetch for strided forward access patterns, but only a few could prefetch for backward strided patterns. These capabilities are becoming more widespread in newer processors.

## OUTPUT
Output format is intended as input to xgraph or some similar program (we use a perl script that produces pic input). There is a set of data produced for each stride. The data set title is the stride size and the data points are the array size in megabytes (floating point value) and the load latency over all points in that array.

## INTERPRETING THE OUTPUT
The output is best examined in a graph where you typically get a graph that has four plateaus. The graph should plotted in log base 2 of the array size on the X axis and the latency on the Y axis. Each stride is then plotted as a curve. The plateaus that appear correspond to the onboard cache (if present), external cache (if present), main memory latency, and TLB miss latency.

As a rough guide, you may be able to extract the latencies of the various parts as follows, but you should really look at the graphs, since these rules of thumb do not always work (some systems do not have onboard cache, for example).

onboard cache

Try stride of 128 and array size of .00098.

external cache

Try stride of 128 and array size of .125.

main memory

Try stride of 128 and array size of 8.

TLB miss

Try the largest stride and the largest array.

## BUGS
This program is dependent on the correct operation of mhz(8). If you are getting numbers that seem off, check that mhz(8) is giving you a clock rate that you believe.

## ACKNOWLEDGEMENT
Funding for the development of this tool was provided by Sun Microsystems Computer Corporation.

## SEE ALSO
lmbench(8), tlb(8), cache(8), line(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


title: lmbench_lat_mmap(8)

text:
# lmbench_lat_mmap(8)

## NAME
lat_mmap - costs of mmapping and unmmapping varying file sizes

## SYNOPSIS
lat_mmap [ -P <parallelism> ] [ -W <warmups> ] [ -N <repetitions> ] size file

## DESCRIPTION
lat_mmap times how fast a mapping can be made and unmade. This is useful because it is a fundemental part of processes that use SunOS style shared libraries (the libraries are mapped in at process start up time and unmapped at process exit).

The benchmark maps in and unmaps the first size bytes of the file repeatedly and reports the average time for one mapping/unmapping.

The size specification may end with ``k'' or ``m'' to mean kilobytes (* 1024) or megabytes (* 1024 * 1024).

## OUTPUT
Output format is "%0.2f %d\n", megabytes, usecs, i.e.,

8.00 1200

## ACKNOWLEDGEMENT
Funding for the development of this tool was provided by Sun Microsystems Computer Corporation.

## SEE ALSO
lmbench(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


title: lmbench_lat_ops(8)

summary: basic CPU operation parallelism

text:
# lmbench_lat_ops(8)

## NAME
lat_ops - basic CPU operation parallelism

## SYNOPSIS
lat_ops [ -W <warmups> ] [ -N <repetitions> ]

## DESCRIPTION
lat_ops measures the latency of basic CPU operations, such as integer ADD.

integer bit, add, mul, div, mod operations

maximum parallelism for integer XOR, ADD, MUL, DIV, MOD operations.

uint64 bit, add, mul, div, mod operations

maximum parallelism for uint64 XOR, ADD, MUL, DIV, MOD operations.

float add, mul, div operations

maximum parallelism for flot ADD, MUL, DIV operations.

double add, mul, div operations

maximum parallelism for flot ADD, MUL, DIV operations.

## BUGS
This benchmark is highly experimental and may sometimes (frequently?) give erroneous results.

## SEE ALSO
lmbench(8), par_ops(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


title: lmbench_lat_pagefault(8)

text:
# lmbench_lat_pagefault(8)

## NAME
lat_pagefault - measure the cost of pagefaulting pages from a file

## SYNOPSIS
lat_pagefault [ -P <parallelism> ] [ -W <warmups> ] [ -N <repetitions> ] file [ file.... ]

## DESCRIPTION
lat_pagefault times how fast a page of a file can be faulted in. The file is flushed from (local) memory by using the msync() interface with the invalidate flag set. (Note that NFS does not send this over the wire so this makes for a handy way to measure the cost of going across the wire.)

The benchmark maps in the entire file and the access pages backwards using a stride of 256K kilobytes.

## OUTPUT
Output format is below; it prints the average cost of page faulting a page.

Pagefaults on <file>: <d> usecs

## BUGS
Using a stride of 256K may be a bad idea because SCSI controllers may have caches bigger than that.

## ACKNOWLEDGEMENT
Funding for the development of this tool was provided by Sun Microsystems Computer Corporation.

## SEE ALSO
lmbench(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


title: lmbench_lat_pipe(8)

text:
# lmbench_lat_pipe(8)

## NAME
lat_pipe - measure interprocess communication latency through pipes

## SYNOPSIS
lat_pipe [ -P <parallelism> ] [ -W <warmups> ] [ -N <repetitions> ]

## DESCRIPTION
lat_pipe uses two processes communicating through a Unix pipe to measure interprocess communication latencies. The benchmark passes a token back and forth between the two processes (this sort of benchmark is frequently referred to as a ``hot potato'' benchmark). No other work is done in the processes.

## OUTPUT
The reported time is in microseconds per round trip and includes the total time, i.e., the context switching overhead is includeded. Output format is like so

Pipe latency: 491 microseconds

## ACKNOWLEDGEMENT
Funding for the development of this tool was provided by Sun Microsystems Computer Corporation.

## SEE ALSO
lmbench(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


title: lmbench_lat_proc(8)

summary: process creation tests

text:
# lmbench_lat_proc(8)

## NAME
lat_proc - process creation tests

## SYNOPSIS
lat_proc [ -P <parallelism> ] [ -W <warmups> ] [ -N <repetitions> ] procedure|fork|exec|shell

## DESCRIPTION
lat_proc creates processes in three different forms, each more expensive than the last. The purposes is to measure the time that it takes to create a basic thread of control.

The forms are listed and described below:

Process fork+exit

The time it takes to split a process into two (nearly) identical copies and have one exit. This is how new processes are created but is not very useful since both processes are doing the same thing.

Process fork+execve

The time it takes to create a new process and have that new process run a new program. This is the inner loop of all shells (command interpreters).

Process fork+/bin/sh -c

The time it takes to create a new process and have that new process run a new program by asking the system shell to find that program and run it. This is how the C library interface called system is implemented. It is the most general and the most expensive.

## OUTPUT
Output is in microseconds per operation like so:

```
Process fork+exit: 6054 microseconds
Process fork+execve: 11212 microseconds
Process fork+/bin/sh -c: 44346 microseconds
```

## ACKNOWLEDGEMENT
Funding for the development of this tool was provided by Sun Microsystems Computer Corporation.

## SEE ALSO
lmbench(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


title: lmbench_lat_rpc(8)

text:
# lmbench_lat_rpc(8)

## NAME
lat_rpc - measure interprocess communication latency via Sun RPC

## SYNOPSIS
lat_rpc -s

lat_rpc [ -P <parallelism> ] [ -W <warmups> ] [ -N <repetitions> ] [ -p tcp|udp ] hostname [ udp|tcp ]

lat_rpc -S hostname

## DESCRIPTION
lat_rpc is a client/server program that measures interprocess communication latencies. The benchmark passes a token back and forth between the two processes (this sort of benchmark is frequently referred to as a ``hot potato'' benchmark). No other work is done in the processes.

This benchmark may be compared to the TCP and UDP forms of the same benchmark to accurately see the cost of using RPC versus the cost of using plain old TCP or UDP sockets. It is worth noting that the RPC form is passing back and forth a single byte, not some long complicated record.

lat_rpc has three forms of usage: as a server (-s), as a client (lat_rpc localhost), and as a shutdown (lat_rpc -S localhost).

The client form may specify the protocol over which the RPCs are performed. The default is to measure performance for both udp and tcp.

## OUTPUT
The reported time is in microseconds per round trip and includes the total time, i.e., the context switching overhead is includeded. Output format is like so

RPC/udp latency using localhost: 1344 microseconds

RPC/tcp latency using localhost: 2089 microseconds

## ACKNOWLEDGEMENT
Funding for the development of this tool was provided by Sun Microsystems Computer Corporation.

## SEE ALSO
lmbench(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


title: lmbench_lat_select(8)

summary: select benchmark

text:
# lmbench_lat_select(8)

## NAME
lat_select - select benchmark

## SYNOPSIS
lat_ctx [ -P <parallelism> ] [ -W <warmups> ] [ -N <repetitions> ] [ n ]

## DESCRIPTION
lat_select measures the time to do a select on n file descriptors.

## ACKNOWLEDGEMENT
Funding for the development of this tool was provided by Sun Microsystems Computer Corporation.

## SEE ALSO
lmbench(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


title: lmbench_lat_sig(8)

summary: select benchmark

text:
# lmbench_lat_sig(8)

## NAME
lat_sig - select benchmark

## SYNOPSIS
lat_ctx [ -P <parallelism> ] [ -W <warmups> ] [ -N <repetitions> ] install|catch|prot [ file ]

## DESCRIPTION
lat_sig measures the time to install and catch signals. It can also measure the time to catch a protection fault.

## ACKNOWLEDGEMENT
Funding for the development of this tool was provided by Sun Microsystems Computer Corporation.

## SEE ALSO
lmbench(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


title: lmbench_lat_syscall(8)

text:
# lmbench_lat_syscall(8)

## NAME
lat_syscall - time simple entry into the operating system

## SYNOPSIS
lat_syscall [ -P <parallelism> ] [ -W <warmups> ] [ -N <repetitions> ] null|read|write|stat|fstat|open [ file ]

## DESCRIPTION
null

measures how long it takes to do getppid(). We chose getppid() because in all UNIX variants we are aware of, it requires a round-trip to/from kernel space and the actual work required inside the kernel is small and bounded.

read

measures how long it takes to read one byte from /dev/zero. Note that some operating systems do not support /dev/zero.

write

times how long it takes to write one byte to /dev/null. This is useful as a lower bound cost on anything that has to interact with the operating system.

stat

measures how long it takes to stat() a file whose inode is already cached.

fstat

measures how long it takes to fstat() an open file whose inode is already cached.

open

measures how long it takes to open() and then close() a file.

## OUTPUT
Output format is

Null syscall: 67 microseconds

## ACKNOWLEDGEMENT
Funding for the development of this tool was provided by Sun Microsystems Computer Corporation.

## SEE ALSO
lmbench(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


title: lmbench_lat_tcp(8)

text:
# lmbench_lat_tcp(8)

## NAME
lat_tcp - measure interprocess communication latency via TCP/IP

## SYNOPSIS
lat_tcp -s

lat_tcp [ -m <message size> ] [ -P <parallelism> ] [ -W <warmups> ] [ -N <repetitions> ] hostname

lat_tcp -S hostname

## DESCRIPTION
lat_tcp is a client/server program that measures interprocess communication latencies. The benchmark passes a message back and forth between the two processes (this sort of benchmark is frequently referred to as a ``hot potato'' benchmark). No other work is done in the processes.

lat_tcp has three forms of usage: as a server (-s), as a client (lat_tcp localhost), and as a shutdown (lat_tcp -S localhost).

## OUTPUT
The reported time is in microseconds per round trip and includes the total time, i.e., the context switching overhead is includeded. Output format is like so

TCP latency using localhost: 700 microseconds

## ACKNOWLEDGEMENT
Funding for the development of this tool was provided by Sun Microsystems Computer Corporation.

## SEE ALSO
lmbench(8), lat_fcntl(8), lat_fifo(8), lat_tcp(8), lat_udp(8), lat_unix(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


title: lmbench_lat_udp(8)

text:
# lmbench_lat_udp(8)

## NAME
lat_udp - measure interprocess communication latency via UDP/IP

## SYNOPSIS
lat_udp -s

lat_udp [ -m <message size> ] [ -P <parallelism> ] [ -W <warmups> ] [ -N <repetitions> ] hostname

lat_udp -S hostname

## DESCRIPTION
lat_udp is a client/server program that measures interprocess communication latencies. The benchmark passes a message back and forth between the two processes (this sort of benchmark is frequently referred to as a ``hot potato'' benchmark). No other work is done in the processes.

lat_udp has three forms of usage: as a server (-s), as a client (lat_udp localhost), and as a shutdown (lat_udp -S localhost).

## OUTPUT
The reported time is in microseconds per round trip and includes the total time, i.e., the context switching overhead is included. Output format is like so

UDP latency using localhost: 650 microseconds

## ACKNOWLEDGEMENT
Funding for the development of this tool was provided by Sun Microsystems Computer Corporation.

## SEE ALSO
lmbench(8), lat_fcntl(8), lat_fifo(8), lat_tcp(8), lat_unix(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


title: lmbench_lat_unix(8)

text:
# lmbench_lat_unix(8)

## NAME
lat_unix - measure interprocess communication latency via UNIX sockets

## SYNOPSIS
lat_unix [ -m <message size> ] [ -P <parallelism> ] [ -W <warmups> ] [ -N <repetitions> ]

## DESCRIPTION
lat_unix is a client/server program that measures interprocess communication latencies. The benchmark passes a message back and forth between the two processes (this sort of benchmark is frequently referred to as a ``hot potato'' benchmark). No other work is done in the processes.

## OUTPUT
The reported time is in microseconds per round trip and includes the total time, i.e., the context switching overhead is includeded. Output format is like so

AF_UNIX sock stream latency: 700 microseconds

## ACKNOWLEDGEMENT
Funding for the development of this tool was provided by Sun Microsystems Computer Corporation.

## SEE ALSO
lmbench(8), lat_fcntl(8), lat_fifo(8), lat_tcp(8), lat_udp(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


title: lmbench_lat_unix_connect(8)

text:
# lmbench_lat_unix_connect(8)

## NAME
lat_unix_connect - measure interprocess connection latency via UNIX sockets

## SYNOPSIS
lat_unix_connect -s

lat_unix_connect [ -P <parallelism> ] [ -W <warmups> ] [ -N <repetitions> ]

lat_unix_connect -S

## DESCRIPTION
lat_unix_connect is a client/server program that measures interprocess connection latencies. The benchmark times the creation and connection of an AF_UNIX socket to a local server.

lat_connect has three forms of usage: as a server (-s), as a client (lat_connect), and as a shutdown (lat_connect -S).

## OUTPUT
The reported time is in microseconds per connection. Output format is like so

UNIX connection cost: 1006 microseconds

## SEE ALSO
lmbench(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


title: lmbench_line(8)

summary: cache line size

text:
# lmbench_line(8)

## NAME
line - cache line size

## SYNOPSIS
line [ -M <len> ] [ -W <warmups> ] [ -N <repetitions> ]

## DESCRIPTION
line tries to determine the cache line size in bytes of the largest cache which is smaller than len bytes.

line creates pointer chains which access the first word on each cache line on a page (randomly meandering through all the lines in a page before jumping to the next page). It measures the average memory latency for a variety of line sizes, starting with a line size of one word. When it finds an increase in the average latency that is significantly larger than the latency for the smaller line size then it assumes that it has found the line size.

This algorithm works because for line sizes less than the true line size, at least two line cache lines fit in the space of a true cache line. Since that cache line will be accessed twice, the first access will cause an expensive cache miss, while the second access will be a cache hit. Once the line cache line is equal to the true cache line size, then all accesses will cause cache misses.

## BUGS
line is an experimental benchmark, but it seems to work well on most systems.

## SEE ALSO
lmbench(8), tlb(8), cache(8), par_mem(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


title: lmbench_lmdd(8)

text:
# lmbench_lmdd(8)

## NAME
lmdd - move io for performance and debugging tests

## SYNOPSIS
lmdd [ option=value ] ...

## DESCRIPTION
lmdd copies a specified input file to a specified output with possible conversions. This program is primarily useful for timing I/O since it prints out the timing statistics after completing.

## OPTIONS
if=name

Input file is taken from name; internal is the default. internal is a special file that acts like Sun's /dev/zero, i.e., it provides a buffer of zeros without doing a system call to get them. The following file names are taken to mean the standard input: -, 0, or stdin.

of=name

Output file is taken from name; internal is the default. internal is a special file that acts like /dev/null, without doing a system call to get rid of the data. The following file names are taken to mean the standard output: -, 1, or stdout.

The following file names are taken to mean the standard error: 2, or stderr.

bs=n

Input and output block size n bytes (default 8192). Note that this is different from dd(1), it has a 512 byte default. Also note that the block size can be followed by 'k' or 'm' to indicate kilo bytes (*1024) or megabytes (*1024*1024), respectively.

ipat=n

If n is non zero, expect a known pattern in the file (see opat). Mismatches will be displayed as "ERROR: off=%d want=%x got=%x". The pattern is a sequence of 4 byte integers with the first 0, second 1, and so on. The default is not to check for the pattern.

opat=n

If n is non zero, generate a known pattern on the output stream. Used for debugging file system correctness. The default is not to generate the pattern.

mismatch=n

If n is non zero, stop at the first mismatched value. Used with ipat.

skip=n

Skip n input blocks before starting copy.

fsync=n

If n is non-zero, call fsync(2) on the output file before exiting or printing timing statistics.

sync=n

If n is non-zero, call sync(2) before exiting or printing timing statistics.

rand=n

This argument, by default off, turns on random behavior. The argument is not a flag, it is a size, that size is used as the upper bound for the seeks. Also note that the block size can be followed by 'k' or 'm' to indicate kilo bytes (*1024) or megabytes (*1024*1024),

flush=n

If n is non-zero and mmap(2) is available, call msync(2) to invalidate the output file. This flushes the file to disk so that you don't have unmount/mount. It is not as good as mount/unmount because it just flushes file pages - it misses the indirect blocks which are still cached. Not supported on all systems, compile time option.

rusage=n

If n is non-zero, print rusage statistics as well as timing statistics. Not supported on all systems, compile time option.

count=n

Copy only n input records.

## EXAMPLES
This is the most common usage, the intent is to measure disk performance. The disk is a spare partition mounted on /spare.

```
# mount /spare
# lmdd if=internal of=/spare/XXX count=1000 fsync=1
7.81 MB in 3.78 seconds (2.0676 MB/sec)
: Flush cache
# umount /spare
# mount /spare
# lmdd if=/spare/XXX of=internal
7.81 MB in 2.83 seconds (2.7611 MB/sec)
```

## AUTHOR
Larry McVoy, lm@sun.com


title: lmbench_mhz(8)

summary: calulate processor clock rate

text:
# lmbench_mhz(8)

## NAME
mhz - calulate processor clock rate

## SYNOPSIS
mhz [-c]

## DESCRIPTION
mhz calculates the processor clock rate and megahertz. It uses an unrolled, interlocked loop of adds or shifts. So far, superscalarness has been defeated on the tested processors (SuperSPARC, RIOS, Alpha).

## OUTPUT
Output format is either just the clock rate as a float (-c) or more verbose

39.80 Mhz, 25 nanosec clock

mhz is described more completely in ``mhz: Anatomy of a microbenchmark'' in Proceedings of 1998 USENIX Annual Technical Conference , June 1998.

## SEE ALSO
lmbench(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


title: lmbench_par_mem(8)

summary: memory parallelism benchmark

text:
# lmbench_par_mem(8)

## NAME
par_mem - memory parallelism benchmark

## SYNOPSIS
par_mem [ -L <line size> ] [ -M <len> ] [ -W <warmups> ] [ -N <repetitions> ]

## DESCRIPTION
par_mem measures the available parallelism in the memory hierarchy, up to len bytes. Modern processors can often service multiple memory requests in parallel, while older processors typically blocked on LOAD instructions and had no available parallelism (other than that provided by cache prefetching). par_mem measures the available parallelism at a variety of points, since the available parallelism is often a function of the data location in the memory hierarchy.

In order to measure the available parallelism par_mem conducts a variety of experiments at each memory size; one for each level of parallelism. It builds a pointer chain of the desired length. It then creates an array of pointers which point to chain entries which are evenly spaced across the chain. Then it starts running the pointers forward through the chain in parallel. It can then measure the average memory latency for each level of parallelism, and the available parallelism is the minimum average memory latency for parallelism 1 divided by the average memory latency across all levels of available parallelism.

For example, the inner loop which measures parallelism 2 would look something like:

for (i = 0; i < N; ++i) { p0 = (char **)*p0; p1 = (char **)*p1; }

in a for loop (the overhead of the for loop is not significant; the loop is an unrolled loop 100 loads long). In this case, if the hardware can process two LOAD operations in parallel, then the overall latency of the loop should be equivalent to that of a single pointer chain, so the measured parallelism would be roughly two. If, however, the hardware can only process a single LOAD operation at once, or if there is (significant) resource contention between the two LOAD operations, then the loop will be much slower than a loop with a single pointer chain, so the measured parallelism will be less than two, and probably no smaller than one.

## OUTPUT
Output format is intended as input to xgraph or some similar program (we use a perl script that produces pic input). There is a set of data produced for each stride. The data set title is the stride size and the data points are the array size in megabytes (floating point value) and the load latency over all points in that array.

## SEE ALSO
lmbench(8), line(8), cache(8), tlb(8), par_ops(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


title: lmbench_par_ops(8)

summary: basic CPU operation parallelism

text:
# lmbench_par_ops(8)

## NAME
par_ops - basic CPU operation parallelism

## SYNOPSIS
par_ops [ -W <warmups> ] [ -N <repetitions> ]

## DESCRIPTION
par_ops measures the available parallelism for basic CPU operations, such as integer ADD. Results are reported as the average operation latency divided by the minimum average operation latency across all levels of parallelism.

integer bit, add, mul, div, mod operations;

maximum parallelism for integer XOR, ADD, MUL, DIV, MOD operations.

uint64 bit, add, mul, div, mod operations;

maximum parallelism for uint64 XOR, ADD, MUL, DIV, MOD operations.

float add, mul, div operations;

maximum parallelism for flot ADD, MUL, DIV operations.

double add, mul, div operations;

maximum parallelism for flot ADD, MUL, DIV operations.

## BUGS
This benchmark is highly experimental and may sometimes (frequently?) give erroneous results.

## SEE ALSO
lmbench(8), lat_ops(8), par_mem(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


title: lmbench_stream(8)

summary: John McCalpin's STREAM benchmark

text:
# lmbench_stream(8)

## NAME
stream - John McCalpin's STREAM benchmark

## SYNOPSIS
stream [ -M <len> ] [ -W <warmups> ] [ -N <repetitions> ]

## DESCRIPTION
stream mimics John McCalpin's STREAM benchmark. It measures memory bandwidth.

## BUGS
stream is an experimental benchmark, but it seems to work well on most systems.

## SEE ALSO
lmbench(8), bw_mem(8), line(8), tlb(8), cache(8), par_mem(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


title: lmbench_tlb(8)

summary: TLB size and latency benchmark

text:
# lmbench_tlb(8)

## NAME
tlb - TLB size and latency benchmark

## SYNOPSIS
tlb [ -L <line size> ] [ -M <len> ] [ -W <warmups> ] [ -N <repetitions> ]

## DESCRIPTION
tlb tries to determine the size, in pages, of the TLB. The largest amount of memory it will examine is len bytes.

tlb compares the memory latency for two different pointer chains. The two chains occupy the same amount of cache space, but they stress the memory subsystem differently. The first chain accesses one word per page, while the second chain randomly jumps through all the lines on a page before jumping to the next page. When all of the pointers reside in the cache (which is the usual case), and all of the pages for the first chain reside in the TLB, then the average memory latencies should be identical. Assuming there is a fixed size TLB, then at some point the number of pages accessed by the first page will be larger than the TLB. At this point the average latency for each memory access for the first chain will be a cache hit plus some fraction of a TLB miss.

Once the TLB boundary is located tlb reports the TLB miss latency as the TLB latency for twice as many pages as the TLB can hold.

## BUGS
tlb is an experimental benchmark, but it seems to work well on most systems. However, if a processor has a TLB hierarchy tlb only finds the top level TLB.

## SEE ALSO
lmbench(8), line(8), cache(8), par_mem(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


logcheck

package: logcheck

title: logcheck(8)

text:
# logcheck(8)

## NAME
logcheck — program to scan system logs for interesting lines

## SYNOPSIS
logcheck [OPTIONS]

## DESCRIPTION
The logcheck program helps spot problems and security violations in your logfiles automatically and will send the results to you periodically in an e-mail. By default logcheck runs as an hourly cronjob just off the hour and after every reboot.

logcheck supports three level of filtering: "paranoid" is for high-security machines running as few services as possible. Don't use it if you can't handle its verbose messages. "server" is the default and contains rules for many different daemons. "workstation" is for sheltered machines and filters most of the messages. The ignore rules work in additive manner. "paranoid" rules are also included at level "server". "workstation" level includes both "paranoid" and "server" rules.

The messages reported are sorted into three layers, system events, security events and attack alerts. The verbosity of system events is controlled by which level you choose, paranoid, server or workstation. However, security events and attack alerts are not affected by this.

## EXAMPLES
logcheck can be invoked directly thanks to su(8) or sudo(8), which change the user ID. The following example checks the logfiles without updating the offset and outputs everything to STDOUT.

sudo -u logcheck logcheck -o -t

## OPTIONS
A summary of options is included below.

-c CFG

Overrule default configuration file.

-d

Debug mode.

-h

Show usage information.

-H

Use this hostname string in the subject of logcheck mail.

-l LOG

Run logfile through logcheck.

-L CFG

Overrule default logfiles list.

-m

Mail report to recipient.

-o

STDOUT mode, not sending mail.

-p

Set the report level to "paranoid".

-r DIR

Overrule default rules directory.

-R

Adds "Reboot:" to the email subject line.

-s

Set the report level to "server".

-S DIR

Overrule default state directory.

-t

Testing mode does not update offset.

-T

Do not remove the TMPDIR.

-u

Enable syslog-summary.

-v

Print current version.

-w

Set the report level to "workstation".

## FILES
/etc/logcheck/logcheck.conf is the main configuration file.

/etc/logcheck/logcheck.logfiles is the list of files to monitor.

/usr/share/doc/logcheck-database/README.logcheck-database.gz for hints on how to write, test and maintain rules.

## EXIT STATUS
0 upon success; 1 upon failure

## SEE ALSO
logtail(8)

## AUTHOR
logcheck is developed by Debian logcheck Team at alioth: http://alioth.debian.org/projects/logcheck/.

This manual page was written by Jon Middleton.


logkeys

package: logkeys

title: logkeys(8)

summary: a GNU/Linux keylogger that works!

text:
# logkeys(8)

## NAME
logkeys - a GNU/Linux keylogger that works!

## SYNOPSIS
logkeys -s [-m keymap | -u] [-o logfile] [-d device]

[--no-func-keys] [--no-timestamps]

[--post-http=URL] [--post-size=SIZE]

logkeys -k

logkeys [--export-keymap=keymap]

## DESCRIPTION
logkeys is a linux keylogger. It is no more advanced than other available linux keyloggers, notably lkl and uberkey, but is a bit newer, more up to date, it doesn't unreliably repeat keys and it shouldn't crash your X. All in all, it just seems to work. It relies on the event interface of Linux input subsystem (normally devices /dev/input/eventX).

Once set, it logs all common character and function keys, while also being fully aware of Shift and AltGr key modifiers. It tries to automatically determine the correct input device, and may in some cases also get the character keys mapping right.

Two helper setuid root programs are shipped with logkeys. llk, which runs etc/logkeys-start.sh script, and llkk, which runs etc/logkeys-kill.sh script. Because llk and llkk are installed setuid root, you can edit the two .sh scripts (mostly just logkeys-start.sh) to your preference, then issue logkeys via llk whenever you have to run it covertly (e.g. when you don't want to su to root or type sudo password).

## OPTIONS
Non-optional arguments are required for short options too.

-s, --start

Starts the keylogging daemon process.

-k, --kill

Terminates the running logkeys process.

-o, --output=logfile

Set ouput log file to logfile. If no -o option is provided, logkeys appends to /var/log/logkeys.log file. If logfile doesn't exist, logkeys creates the file with 600 permissions.

See also LOGFILE FORMAT section.

-m, --keymap=keymap

Use file keymap as input keymap for processing pressed keys.

This option works best if keymap is hand corrected file, which had been previously exported by --export-keymap.

See also KEYMAP FORMAT section.

-m and -u option are mutually exclusive.

-d, --device=device

Use device as keyboard input event device instead of /dev/input/eventX default.

You can determine the keyboard device to be used by examining /proc/bus/input/devices.

-u, --us-keymap

This option makes logkeys interpret keys as on standard US keyboard.

-u and -m option are mutually exclusive.

--export-keymap=keymap

This option makes logkeys export dynamic keymap as obtained from dumpkeys(1) to file keymap and then exit.

keymap can later be used with -m option to override automatic keymap "calculation", which may be wrong.

It is advised that you manually edit keymap and correct any mistakes as well as complete deficient entries. It is also advised that you use --export-keymap on a virtual terminal outside of X (/dev/ttyX).

See section KEYMAP FORMAT for exported keymap format.

--no-func-keys

This option makes logkeys log all and only character key presses (1, 2, ..., q, w, e, ..., a, s, d, f, ..., ", @, \, ...).

This option may be useful when correct keymap can reliably be expected (i.e. by providing it with -m option). Then only character keys are logged, influenced by Shift and AltGr modifiers.

--no-timestamps

When this option is set, logkeys doesn't prepend timestamp to each line of log file. Timestamps are only logged when logkeys starts and stops.

--post-size=SIZE

When log size reaches SIZE, the current log filename is appended .X, where X is ascending number (e.g. logfile.1).

When that happens, logkeys starts remote uploading process and all logfile.X files are uploaded as specified by --post-http or --post-irc options.

If --post-size is set, but no post method is set, then the logfile is only truncated when it reaches SIZE, renamed to logfile.X, and a new blank logfile is created for active logging.

If --post-size is not set, but post method is, then the default SIZE of 500 KB (500.000 B) is used.

If --post-size is not set, and neither is any post method, then logkeys appends to the single specified log file.

SIZE can be an integer bytesize, or an intger followed by K or M for kilobytes or megabytes, respectively.

--post-http=URL

This option tells logkeys to POST the log file to URL, where it is preferrably greeted by a (PHP) script.

The file is sent with header Content-Type: multipart/form-data as file, so it is accessible in PHP via $_FILES['file'] variable.

## FILES
/var/log/logkeys.log

When -o option is not used, logkeys appends to this default log file.

etc/logkeys-start.sh

Setuid root program llk runs this script. Edit the contents to suit your needs.

etc/logkeys-stop.sh

Setuid root program llkk runs this script. Default value should work well.

## LOGFILE FORMAT
Log files are UTF-8 encoded.

Each logging session is enclosed in "Logging started... [<timestamp>]" and "Logging stopped at <timestamp>" strings. Whenever Enter key (Return key) or Ctrl+C or Ctrl+D combination is pressed, a timestamp is appended on a new line (provided --no-timestamps is not in effect).

Timestamp format is "%F %T%z", which results in "YYYY-mm-dd HH:MM:SS+ZZZZ". Timestamp is separated from the logged keys by one '>' symbol.

All character key presses are logged as they appear. All function key presses are replaced with strings as obtained from keymap file, or as hardcoded when no keymap file is provided.

If a key is pressed down long enough so it repeats, it is logged only once and then "<#+DD>" is appended, which hints the key was repeated DD more times. The DD decimal figure is not to be relied on.

If a keypress results in keycode, which is not recognized (i.e. key not found on a standard US or Intl 105-key keyboard), then the string "<E-XX>" is appended, where XX is the received keycode in hexadecimal format. All new "WWW", "E-Mail", "Volume+", "Media", "Help", etc. keys will result in such error strings.

Using US keyboard layout, one example log file could look like:

Logging started ...

2009-12-11 09:58:17+0100 > llk

2009-12-11 09:58:20+0100 > sudo cp <RShift>~/foo.<Tab> /usr/bin

2009-12-11 09:58:26+0100 > <LShift>R00<LShift>T_p455\\/0rD

2009-12-11 09:58:39+0100 > <Up><Up><Home>sudo

2009-12-11 09:58:44+0100 > c<#+53><BckSp><#+34><LCtrl>c

2009-12-11 09:58:54+0100 > llkk

Logging stopped at 2009-12-11 09:58:54+0100

If the same log was obtained by a logkeys process invoked with --no-func-keys option, it would look like:

Logging started ...

2009-12-11 09:58:17+0100 > llk

2009-12-11 09:58:20+0100 > sudo cp ~/foo. /usr/bin

2009-12-11 09:58:26+0100 > R00T_p455\\/0rD

2009-12-11 09:58:39+0100 > sudo

2009-12-11 09:58:44+0100 > c<#+53>c

2009-12-11 09:58:54+0100 > llkk

Logging stopped at 2009-12-11 09:58:54+0100

Even when --no-func-keys is in effect, Space and Tab key presses are logged as a single space character.

## KEYMAP FORMAT
The keymap file is expected to be UTF-8 encoded.

Each line of file represents either one character key or one function key. The format specifies at least one and up to three space-delimited characters on character key lines (first without modifiers, optional second with Shift in action, optional third with AltGr in action), and up to 7 characters long string on function key lines.

First three lines in a Slovene keymap file look like:

<Esc>

1 ! ~

2 " ˇ

How does one know which lines belong to character keys and which lines to function keys?

Well, the easiest way is to use --export-keymap, and examine the exported keymap. Make sure you export in a virtual terminal (ttyX) and not in X as this way more keys could get exported correctly (don't ask me why).

Basically, --export-keymap ouputs 106 lines for 106 keys, even if some of those keys aren't located on your keyboard. Lines 1, 14, 15, 28, 29, 42, 54-83, 85-106 belong to function keys, all other lines (2-13, 16-27, 30-41, 43-53, 84) belong to character keys.

Line 57 is reserved for Space and it should always be ' '. Line 84 is reserved for the key just right to left Shift that is present on some international layouts. Other lines can be quite reliably determined by looking at one exported keymap. The keys generally follow the order of their appearance on the keyboard, top-to-bottom left-to-right.

If you create full and completely valid keymap for your particular language, please upload it to project website or send it to me by e-mail. Thanks.

## EXAMPLES
To print short help:

$ logkeys

To start logging to a custom log file with dynamically generated keymap:

$ logkeys --start --output /home/user/.secret/log

To start logging to default log file on a standard US keyboard:

$ logkeys --start --us-keymap

To export dynamically generated keymap to file:

$ logkeys --export-keymap my_keymap

To start logging to default log file with a custom keymap:

$ logkeys --start --keymap my_keymap

To use a custom event device (e.g. /dev/input/event4):

$ logkeys --start --device event4

To end running logkeys process:

$ logkeys --kill

After etc/logkeys-start.sh is updated to one's liking, helper programs bin/llk (start) and bin/llkk (kill) can be used as well.

## BUGS
logkeys relies on numeric output of dumpkeys(1), which keymaps(5) manual page specifically discourages as unportable.

Be nice and hope nothing breaks.

If you come across any bugs, please report them on project website, issues page:

http://code.google.com/p/logkeys/issues/

## AUTHOR
logkeys was written by Kernc <kerncece+logkeys@gmail.com> with much help from the community.

You can always obtain the latest version and information at project website: <http://code.google.com/p/logkeys/>.


logrotate

package: logrotate

title: logrotate(8)

text:
# logrotate(8)

## NAME
logrotate ‐ rotates, compresses, and mails system logs

## SYNOPSIS
logrotate [--force] [--debug] [--state file] [--skip-state-lock] [--verbose] [--log file] [--mail command] config_file [config_file2 ...]

## DESCRIPTION
logrotate is designed to ease administration of systems that generate large numbers of log files. It allows automatic rotation, compression, removal, and mailing of log files. Each log file may be handled daily, weekly, monthly, or when it grows too large.

Normally, logrotate is run as a daily cron job. It will not modify a log more than once in one day unless the criterion for that log is based on the log's size and logrotate is being run more than once each day, or unless the -f or --force option is used.

Any number of config files may be given on the command line. Later config files may override the options given in earlier files, so the order in which the logrotate config files are listed is important. Normally, a single config file which includes any other config files which are needed should be used. See below for more information on how to use the include directive to accomplish this. If a directory is given on the command line, every file in that directory is used as a config file.

If no command line arguments are given, logrotate will print version and copyright information, along with a short usage summary. If any errors occur while rotating logs, logrotate will exit with non-zero status, although the state file will be updated.

## OPTIONS
-f, --force

Tells logrotate to force the rotation, even if it doesn't think this is necessary. Sometimes this is useful after adding new entries to a logrotate config file, or if old log files have been removed by hand, as the new files will be created, and logging will continue correctly.

-d, --debug

Turn on debug mode, which means that no changes are made to the logs and the logrotate state file is not updated. Only debug messages are printed.

-s, --state statefile

Tells logrotate to use an alternate state file. This is useful if logrotate is being run as a different user for various sets of log files. To prevent parallel execution logrotate by default acquires a lock on the state file, if it cannot be acquired logrotate will exit with value 3. The default state file is /var/lib/status. If /dev/null is given as the state file, then logrotate will not try to lock or write the state file.

--skip-state-lock

Do not lock the state file, for example if locking is unsupported or prohibited.

-v, --verbose

Turns on verbose mode, for example to display messages during rotation.

-l, --log file

Tells logrotate to log verbose output into the log_file. The verbose output logged to that file is the same as when running logrotate with -v switch. The log file is overwritten on every logrotate execution.

-m, --mail command

Tells logrotate which command to use when mailing logs. This command should accept the following arguments:

1) the subject of the message given with '-s subject'

2) the recipient.

The command must then read a message on standard input and mail it to the recipient. The default mail command is /bin/mail.

--usage

Prints a short usage message.

-?, --help

Prints help message.

--version

Display version information.

## CONFIGURATION FILE
logrotate reads everything about the log files it should be handling from the series of configuration files specified on the command line. Each configuration file can set global options (local definitions override global ones, and later definitions override earlier ones) and specify logfiles to rotate. Global options do not affect preceding include directives. A simple configuration file looks like this:

```
# sample logrotate configuration file
compress
/var/log/messages {

    rotate 5

    weekly

    postrotate

        /usr/bin/killall -HUP syslogd

    endscript
}
"/var/log/httpd/access.log" /var/log/httpd/error.log {

    rotate 5

    mail recipient@example.org

    size 100k

    sharedscripts

    postrotate

        /usr/bin/killall -HUP httpd

    endscript
}
/var/log/news/* {

    monthly

    rotate 2

    olddir /var/log/news/old

    missingok

    sharedscripts

    postrotate

        kill -HUP $(cat /var/run/inn.pid)

    endscript

    nocompress
}
~/log/*.log {}
```

The first few lines set global options; in the example, logs are compressed after they are rotated. Note that comments may appear anywhere in the config file as long as the first non-whitespace character on the line is a #.

Values are separated from directives by whitespace and/or an optional =. Numbers must be specified in a format understood by strtoul(3).

The next section of the config file defines how to handle the log file /var/log/messages. The log will go through five weekly rotations before being removed. After the log file has been rotated (but before the old version of the log has been compressed), the command /usr/bin/killall -HUP syslogd will be executed.

The next section defines the parameters for both /var/log/httpd/access.log and /var/log/httpd/error.log. Each is rotated whenever it grows over 100 kilobytes in size, and the old logs files are mailed (uncompressed) to recipient@example.org after going through 5 rotations, rather than being removed. The sharedscripts means that the postrotate script will only be run once (after the old logs have been compressed), not once for each log which is rotated. Note that log file names may be enclosed in quotes (and that quotes are required if the name contains spaces). Normal shell quoting rules apply, with ', ", and \ characters supported.

The next section defines the parameters for all of the files in /var/log/news. Each file is rotated on a monthly basis.

The last section uses tilde expansion to rotate log files in the home directory of the current user. This is only available, if your glob library supports tilde expansion. GNU glob does support this.

Please use wildcards with caution. If you specify *, logrotate will rotate all files, including previously rotated ones. A way around this is to use the olddir directive or a more exact wildcard (such as *.log).

Please note, by default when using systemd(1), the option ProtectSystem=full is set in the logrotate.service file. This prevents logrotate from modifying logs in /etc and /usr.

Here is more information on the directives which may be included in a logrotate configuration file:

## CONFIGURATION FILE DIRECTIVES
These directives may be included in a logrotate configuration file:

### Rotation
rotate count

Log files are rotated count times before being removed or mailed to the address specified in a mail directive. If count is 0, old versions are removed rather than rotated. If count is -1, old logs are not removed at all, except they are affected by maxage (use with caution, may waste performance and disk space). Default is 0.

olddir directory

Logs are moved into directory for rotation. The directory must be on the same physical device as the log file being rotated, unless copy, copytruncate or renamecopy option is used. The directory is assumed to be relative to the directory holding the log file unless an absolute path name is specified. When this option is used all old versions of the log end up in directory. This option may be overridden by the noolddir option.

noolddir

Logs are rotated in the directory they normally reside in (this overrides the olddir option).

su user group

Rotate log files set under this user and group instead of using default user/group (usually root). user specifies the user used for rotation and group specifies the group used for rotation (see the section USER AND GROUP for details). If the user/group you specify here does not have sufficient privilege to make files with the ownership you've specified in a create directive, it will cause an error. If logrotate runs with root privileges, it is recommended to use the su directive to rotate files in directories that are directly or indirectly in control of non-privileged users.

### Frequency
hourly

Log files are rotated every hour. Note that usually logrotate is configured to be run by cron daily (or by logrotate.timer when using systemd(1)). You have to change this configuration and run logrotate hourly to be able to really rotate logs hourly.

daily

Log files are rotated every day.

weekly [weekday]

Log files are rotated once each weekday, or if the date is advanced by at least 7 days since the last rotation (while ignoring the exact time). The weekday interpretation is following: 0 means Sunday, 1 means Monday, ..., 6 means Saturday; the special value 7 means each 7 days, irrespectively of weekday. Defaults to 0 if the weekday argument is omitted.

monthly

Log files are rotated the first time logrotate is run in a month (this is normally on the first day of the month).

yearly

Log files are rotated if the current year is not the same as the last rotation.

size size

Log files are rotated only if they grow bigger than size bytes. If size is followed by k, the size is assumed to be in kilobytes. If M is used, the size is in megabytes, and if G is used, the size is in gigabytes. So size 100, size 100k, size 100M and size 100G are all valid. This option is mutually exclusive with the time interval options, and it causes log files to be rotated without regard for the last rotation time, if specified after the time criteria (the last specified option takes the precedence).

### File selection
missingok

If the log file is missing, go on to the next one without issuing an error message. See also nomissingok.

nomissingok

If a log file does not exist, issue an error. This is the default.

ifempty

Rotate the log file even if it is empty, overriding the notifempty option (ifempty is the default).

notifempty

Do not rotate the log if it is empty (this overrides the ifempty option).

minage count

Do not rotate logs which are less than <count> days old.

maxage count

Remove rotated logs older than <count> days. The age is only checked if the logfile is to be rotated. rotate -1 does not hinder removal. The files are mailed to the configured address if maillast and mail are configured.

minsize size

Log files are rotated when they grow bigger than size bytes, but not before the additionally specified time interval (daily, weekly, monthly, or yearly). The related size option is similar except that it is mutually exclusive with the time interval options, and it causes log files to be rotated without regard for the last rotation time, if specified after the time criteria (the last specified option takes the precedence). When minsize is used, both the size and timestamp of a log file are considered.

maxsize size

Log files are rotated when they grow bigger than size bytes even before the additionally specified time interval (daily, weekly, monthly, or yearly). The related size option is similar except that it is mutually exclusive with the time interval options, and it causes log files to be rotated without regard for the last rotation time, if specified after the time criteria (the last specified option takes the precedence). When maxsize is used, both the size and timestamp of a log file are considered.

tabooext [+] list

The current taboo extension list is changed (see the include directive for information on the taboo extensions). If a + precedes the list of extensions, the current taboo extension list is augmented, otherwise it is replaced. At startup, the taboo extension list ,v, .cfsaved, .disabled, .dpkg-bak, .dpkg-del, .dpkg-dist, .dpkg-new, .dpkg-old, .rhn-cfg-tmp-*, .rpmnew, .rpmorig, .rpmsave, .swp, .ucf-dist, .ucf-new, .ucf-old, ~

taboopat [+] list

The current taboo glob pattern list is changed (see the include directive for information on the taboo extensions and patterns). If a + precedes the list of patterns, the current taboo pattern list is augmented, otherwise it is replaced. At startup, the taboo pattern list is empty.

### Files and Folders
create mode owner group, create owner group

Immediately after rotation (before the postrotate script is run) the log file is created (with the same name as the log file just rotated). mode specifies the mode for the log file in octal (the same as chmod(2)), owner specifies the user who will own the log file, and group specifies the group the log file will belong to (see the section USER AND GROUP for details). Any of the log file attributes may be omitted, in which case those attributes for the new file will use the same values as the original log file for the omitted attributes. This option can be disabled using the nocreate option.

nocreate

New log files are not created (this overrides the create option).

createolddir mode owner group

If the directory specified by olddir directive does not exist, it is created. mode specifies the mode for the olddir directory in octal (the same as chmod(2)), owner specifies the user who will own the olddir directory, and group specifies the group the olddir directory will belong to (see the section USER AND GROUP for details). This option can be disabled using the nocreateolddir option.

nocreateolddir

olddir directory is not created by logrotate when it does not exist.

copy

Make a copy of the log file, but don't change the original at all. This option can be used, for instance, to make a snapshot of the current log file, or when some other utility needs to truncate or parse the file. When this option is used, the create option will have no effect, as the old log file stays in place. The copy option allows storing rotated log files on the different devices using olddir directive.

nocopy

Do not copy the original log file and leave it in place. (this overrides the copy option).

copytruncate

Truncate the original log file to zero size in place after creating a copy, instead of moving the old log file and optionally creating a new one. It can be used when some program cannot be told to close its logfile and thus might continue writing (appending) to the previous log file forever. Note that there is a very small time slice between copying the file and truncating it, so some logging data might be lost. When this option is used, the create option will have no effect, as the old log file stays in place. The copytruncate option allows storing rotated log files on the different devices using olddir directive. The copytruncate option implies norenamecopy.

nocopytruncate

Do not truncate the original log file in place after creating a copy (this overrides the copytruncate option).

renamecopy

Log file is renamed to temporary filename in the same directory by adding ".tmp" extension to it. After that, postrotate script is run and log file is copied from temporary filename to final filename. In the end, temporary filename is removed. The renamecopy option allows storing rotated log files on the different devices using olddir directive. The renamecopy option implies nocopytruncate.

norenamecopy

Do not rename and copy the original log file (this overrides the renamecopy option).

shred

Delete log files using shred -u instead of unlink(). This should ensure that logs are not readable after their scheduled deletion; this is off by default. See also noshred.

noshred

Do not use shred when deleting old log files. See also shred.

shredcycles count

Asks GNU shred(1) to overwrite log files count times before deletion. Without this option, shred's default will be used.

allowhardlink

Rotate files with multiple hard links; this is off by default. The target file might get emptied, e.g. with shred or copytruncate. Use with caution, especially when the log files are rotated as root.

noallowhardlink

Do not rotate files with multiple hard links. See also allowhardlink.

### Compression
compress

Old versions of log files are compressed with xz(1) by default. See also nocompress.

nocompress

Old versions of log files are not compressed. See also compress.

compresscmd

Specifies which command to use to compress log files. The default is xz(1). See also compress.

uncompresscmd

Specifies which command to use to uncompress log files. The default is unxz(1).

compressext

Specifies which extension to use on compressed logfiles, if compression is enabled. The default follows that of the configured compression command.

compressoptions

Command line options may be passed to the compression program, if one is in use. The default, for xz(1), is "-6" (biased towards high compression at the expense of speed). If you use a different compression command, you may need to change the compressoptions to match.

delaycompress

Postpone compression of the previous log file to the next rotation cycle. This only has effect when used in combination with compress. It can be used when some program cannot be told to close its logfile and thus might continue writing to the previous log file for some time.

nodelaycompress

Do not postpone compression of the previous log file to the next rotation cycle (this overrides the delaycompress option).

### Filenames
extension ext

Log files with ext extension can keep it after the rotation. If compression is used, the compression extension (normally .xz) appears after ext. For example you have a logfile named mylog.foo and want to rotate it to mylog.1.foo.xz instead of mylog.foo.1.xz.

addextension ext

Log files are given the final extension ext after rotation. If the original file already ends with ext, the extension is not duplicated, but merely moved to the end, that is both filename and filenameext would get rotated to filename.1ext. If compression is used, the compression extension (normally .xz) appears after ext.

start count

This is the number to use as the base for rotation. For example, if you specify 0, the logs will be created with a .0 extension as they are rotated from the original log files. If you specify 9, log files will be created with a .9, skipping 0–8. Files will still be rotated the number of times specified with the rotate directive.

dateext

Archive old versions of log files adding a date extension like YYYYMMDD instead of simply adding a number. The extension may be configured using the dateformat and dateyesterday options.

nodateext

Do not archive old versions of log files with date extension (this overrides the dateext option).

dateformat format_string

Specify the extension for dateext using the notation similar to strftime(3) function. Only %Y %m %d %H %M %S %V and %s specifiers are allowed. The default value is -%Y%m%d except hourly, which uses -%Y%m%d%H as default value. Note that also the character separating log name from the extension is part of the dateformat string. The system clock must be set past Sep 9th 2001 for %s to work correctly. Note that the datestamps generated by this format must be lexically sortable (that is first the year, then the month then the day. For example 2001/12/01 is ok, but 01/12/2001 is not, since 01/11/2002 would sort lower while it is later). This is because when using the rotate option, logrotate sorts all rotated filenames to find out which logfiles are older and should be removed.

dateyesterday

Use yesterday's instead of today's date to create the dateext extension, so that the rotated log file has a date in its name that is the same as the timestamps within it.

datehourago

Use hour ago instead of current date to create the dateext extension, so that the rotated log file has a hour in its name that is the same as the timestamps within it. Useful with rotate hourly.

### Mail
mail address

When a log is rotated out of existence, it is mailed to address. If no mail should be generated by a particular log, the nomail directive may be used.

nomail

Do not mail old log files to any address.

mailfirst

When using the mail command, mail the just-rotated file, instead of the about-to-expire file.

maillast

When using the mail command, mail the about-to-expire file, instead of the just-rotated file (this is the default).

### Additional config files
include file_or_directory

Reads the file given as an argument as if it was included inline where the include directive appears. If a directory is given, most of the files in that directory are read in alphabetic order before processing of the including file continues. The only files which are ignored are files which are not regular files (such as directories and named pipes) and files whose names end with one of the taboo extensions or patterns, as specified by the tabooext or taboopat directives, respectively. The given path may start with ~/ to make it relative to the home directory of the executing user. For security reasons configuration files must not be group-writable nor world-writable.

### Scripts
sharedscripts

Normally, prerotate and postrotate scripts are run for each log which is rotated and the absolute path to the log file is passed as first argument to the script. That means a single script may be run multiple times for log file entries which match multiple files (such as the /var/log/news/* example). If sharedscripts is specified, the scripts are only run once, no matter how many logs match the wildcarded pattern, and whole pattern is passed to them. However, if none of the logs in the pattern require rotating, the scripts will not be run at all. If the scripts exit with error (or any log fails to rotate), the remaining actions will not be executed for any logs. This option overrides the nosharedscripts option.

nosharedscripts

Run prerotate and postrotate scripts for every log file which is rotated (this is the default, and overrides the sharedscripts option). The absolute path to the log file is passed as first argument to the script. The absolute path to the final rotated log file is passed as the second argument to the postrotate script. If the scripts exit with error, the remaining actions will not be executed for the affected log only.

firstaction

script

endscript

The script is executed once before all log files that match the wildcarded pattern are rotated, before the prerotate script is run and only if at least one log will actually be rotated. These directives may only appear inside a log file definition. The whole pattern is passed to the script as its first argument. If the script exits with an error, no further processing is done. See also lastaction and the SCRIPTS section.

lastaction

script

endscript

The script is executed once after all log files that match the wildcarded pattern are rotated, after the postrotate script is run and only if at least one log is rotated. These directives may only appear inside a log file definition. The whole pattern is passed to the script as its first argument. If the script exits with an error, just an error message is shown (as this is the last action). See also firstaction and the SCRIPTS section.

prerotate

script

endscript

The script is executed before the log file is rotated and only if the log will actually be rotated. These directives may only appear inside a log file definition. Normally, the absolute path to the log file is passed as the first argument to the script. If sharedscripts is specified, the whole pattern is passed to the script. See also postrotate and the SCRIPTS section. See sharedscripts and nosharedscripts for error handling.

postrotate

script

endscript

The script is executed after the log file is rotated. These directives may only appear inside a log file definition. Normally, the absolute path to the log file is passed as the first argument to the script and the absolute path to the final rotated log file is passed as the second argument to the script. If sharedscripts is specified, the whole pattern is passed as the first argument to the script, and the second argument is omitted. See also prerotate and the SCRIPTS section. See sharedscripts and nosharedscripts for error handling.

preremove

script

endscript

The script is executed once just before removal of a log file. logrotate will pass the name of file which is soon to be removed as the first argument to the script. See also firstaction and the SCRIPTS section.

## SCRIPTS
The lines between the starting keyword (e.g. prerotate) and endscript (both of which must appear on lines by themselves) are executed (using /bin/sh). The script inherits some traits from the logrotate process, including stderr, stdout, the current directory, the environment, and the umask. Scripts are run as the invoking user and group, irrespective of any su directive. If the --log flag was specified, file descriptor 3 is the log file. The current working directory is unspecified.

## USER AND GROUP
User and group identifiers are resolved first by trying the textual representation and, in case it fails, afterwards by the numeric value.

## FILES
/var/lib/status

Default state file.

/etc/logrotate.conf

Configuration options.

## SEE ALSO
chmod(2), unxz(1), xz(1), mail(1), shred(1), strftime(3), strtoul(3), <https://github.com/logrotate/logrotate>

## AUTHORS

```
Erik Troan, Preston Brown, Jan Kaluza.
<https://github.com/logrotate/logrotate>
```


logtail

package: logtail

title: logtail(8)

text:
# logtail(8)

## NAME
logtail - print log file lines that have not been read

## SYNOPSIS
logtail [-t] -flogfile [-ooffsetfile]

## DESCRIPTION
logtail reads a specified file (usually a log file) and writes to the standard output that part of it which has not been read by previous runs of logtail. It prints the appropriate number of bytes from the end of logfile, assuming that all changes that are made to it are to add new characters to it.

logfile must be a plain file. A symlink is not allowed.

logtail stores the information about how much of it has already been read in a separate file called offsetfile. offsetfile can be omitted. If omitted, the file named logfile.offset in the same directory which contains logfile is used by default.

If offsetfile is not empty, the inode of logfile is checked. If the inode is changed, logtail simply prints the entire file. If the inode is not changed but logfile is shorter than it was at the last run of logtail, it writes a warning message to the standard output.

## OPTIONS
-f

logfile to be read after offset

-o

offsetfile stores offset of previous run

-t

test mode - do not change offset in offsetfile

## RETURN VALUES
0

successful

65

cannot get the size of logfile

66

logfile does not exist, is not a plain file, or is not readable

73

cannot write offsetfile

## AUTHOR
The original logtail was written in C by Craig H. Rowland <crowland@psionic.com>. This version of logtail is a Perl reimplementation by Paul Slootman <paul@debian.org>. Enhanced by the Debian Logcheck Team <logcheck-devel@lists.alioth.debian.org>.

This manual was written by Oohara Yuuma <oohara@libra.interq.or.jp>.

## SEE ALSO
logcheck(8)


title: logtail2(8)

text:
# logtail2(8)

## NAME
logtail2 - print log file lines that have not been read

## SYNOPSIS
logtail2 [-t] -flogfile [-ooffsetfile]

## DESCRIPTION
logtail2 reads a specified file (usually a log file) and writes to the standard output that part of it which has not been read by previous runs of logtail2. It prints the appropriate number of bytes from the end of logfile, assuming that all changes that are made to it are to add new characters to it.

logfile must be a plain file. A symlink is not allowed.

logtail2 stores the information about how much of it has already been read in a separate file called offsetfile. offsetfile can be omitted. If omitted, the file named logfile.offset in the same directory which contains logfile is used by default.

If offsetfile is not empty, the inode of logfile is checked. If the inode is changed, logtail2 uses the heuristics stored in /usr/share/logtail/detectrotate/ to find a file that might be the rotated logfile and prints it starting with the stored offset. It then proceeds to simply print the entire new file and generates a new offsetfile. If the inode is not changed but logfile is shorter than it was at the last run of logtail2, it writes a warning message to the standard output.

## OPTIONS
-f

logfile to be read after offset

-o

offsetfile stores offset of previous run

-t

test mode - do not change offset in offsetfile

## RETURN VALUES
0

successful

65

cannot get the size of logfile

66

general file or directory access issue

73

cannot write offsetfile

## AUTHOR
The original logtail was written in C by Craig H. Rowland <crowland@psionic.com>. This version of logtail is a modification of Paul Slootman's re-implementation in perl. enhanced by the Debian Logcheck Team <logcheck-devel@lists.alioth.debian.org>.

This manual was written by Oohara Yuuma <oohara@libra.interq.or.jp> and enhanced by the Debian Logcheck Team <logcheck-devel@lists.alioth.debian.org>..

## SEE ALSO
logcheck(8)


logwatch

package: logwatch

title: logwatch(8)

summary: system log analyzer and reporter

text:
# logwatch(8)

## NAME
logwatch - system log analyzer and reporter

## SYNOPSIS
logwatch [--detail level ] [--logfile log-file-group ] [--service service-name ] [--mailto address ] [--archives] [--range range ] [--debug level ] [--filename file-name ] [--logdir directory ] [--hostname hostname ] [--hostformat host based options ] [--output output-type ] [--format report format ] [--encode encoding to use ] [--numeric] [--version] [--help|--usage]

## DESCRIPTION
Logwatch is a customizable, pluggable log-monitoring system. It will go through your logs for a given period of time and make a report in the areas that you wish with the detail that you wish. Logwatch is being used for Linux and many types of UNIX.

## OPTIONS
--detail level

This is the detail level of the report. level can be a positive integer, or high, med, low, which correspond to the integers 10, 5, and 0, repectively.

--logfile log-file-group

This will force Logwatch to process only the set of logfiles defined by log-file-group (i.e. messages, xferlog, ...). Logwatch will therefore process all services that use those logfiles. This option can be specified more than once to specify multiple logfile-groups.

--service service-name

This will force Logwatch to process only the service specified in service-name (i.e. login, pam, identd, ...). Logwatch will therefore also process any log-file-groups necessary to process these services. This option can be specified more than once to specify multiple services to process. A useful service-name is All which will process all services (and logfile-groups) for which you have filters installed.

--mailto address

Mail the results to the email address or user specified in address. This option overrides the --print option.

--range range

You can specify a date-range to process. Common ranges are Yesterday, Today, All, and Help. Additional options are listed when invoked with the Help parameter.

--archives

Each log-file-group has basic logfiles (i.e. /var/log/messages) as well as archives (i.e. /var/log/messages.? or /var/log/messages.?.gz). When used with "--range all", this option will make Logwatch search through the archives in addition to the regular logfiles. For other values of --range, Logwatch will search the appropriate archived logs.

--debug level

For debugging purposes. level can range from 0 to 100. This will really clutter up your output. You probably don't want to use this.

--filename file-name

Save the output to file-name instead of displaying or mailing it.

--logdir directory

Look in directory for log subdirectories or log files instead of the default directory.

--hostname hostname

Use hostname for the reports instead of this system's hostname. In addition, if HostLimit is set in the logwatch.conf configuration file (see MORE INFORMATION, below), then only logs from this hostname will be processed (where appropriate).

--numeric

Inhibits additional name lookups, displaying IP addresses numerically.

--usage

Displays usage information

--help

same as --usage.

## FILES
/usr/share/logwatch/

This directory contains all the perl executables and configuration files shipped with the logwatch distribution.

/etc/logwatch

This directory contains local configuration files that override the default configuration. See MORE INFORMATION below for more information.

## EXAMPLES
logwatch --service ftpd-xferlog --range all --detail high --print --archives

This will print out all FTP transfers that are stored in all current and archived xferlogs.

logwatch --service pam_pwdb --range yesterday --detail high --print This will print out login information for the previous day...

## MORE INFORMATION
The directory /usr/share/doc/logwatch-* contains several files with additional documentation:

HOWTO-Customize-LogWatch

Documents the directory structure of Logwatch configuration and executable files, and describes how to customize Logwatch by overriding these default files.

LICENSE Describes the License under which Logwatch is distributed. Additional clauses may be specified in individual files.

README Describes how to install, where to find it, mailing lists, and other useful information.

## AUTHOR
Kirk Bauer <kirk@kaybee.org>

http://www.kaybee.org/~kirk

ftp://ftp.kaybee.org/pub/redhat/RPMS


losetup

package: losetup

title: losetup(8)

summary: set up and control loop devices

text:
# losetup(8)

## NAME
losetup - set up and control loop devices

## SYNOPSIS
Get info:

losetup [loopdev]

losetup -l [-a]

losetup -j file [-o offset]

Detach a loop device:

losetup -d loopdev ...

Detach all associated loop devices:

losetup -D

Set up a loop device:

losetup [-o offset] [--sizelimit size] [--sector-size size] [-Pr] [--show] -f|loopdev file

Resize a loop device:

losetup -c loopdev

## DESCRIPTION
losetup is used to associate loop devices with regular files or block devices, to detach loop devices, and to query the status of a loop device. If only the loopdev argument is given, the status of the corresponding loop device is shown. If no option is given, all loop devices are shown.

Note that the old output format (i.e., losetup -a) with comma-delimited strings is deprecated in favour of the --list output format.

It’s possible to create more independent loop devices for the same backing file. This setup may be dangerous, can cause data loss, corruption and overwrites. Use --nooverlap with --find during setup to avoid this problem.

The loop device setup is not an atomic operation when used with --find, and losetup does not protect this operation by any lock. The number of attempts is internally restricted to a maximum of 16. It is recommended to use for example flock(1) to avoid a collision in heavily parallel use cases.

## OPTIONS
The size and offset arguments may be followed by the multiplicative suffixes KiB (=1024), MiB (=1024*1024), and so on for GiB, TiB, PiB, EiB, ZiB and YiB (the "iB" is optional, e.g., "K" has the same meaning as "KiB") or the suffixes KB (=1000), MB (=1000*1000), and so on for GB, TB, PB, EB, ZB and YB.

-a, --all

Show the status of all loop devices. Note that not all information is accessible for non-root users. See also --list. The old output format (as printed without --list) is deprecated.

-d, --detach loopdev...

Detach the file or device associated with the specified loop device(s). Note that since Linux v3.7 kernel uses "lazy device destruction". The detach operation does not return EBUSY error anymore if device is actively used by system, but it is marked by autoclear flag and destroyed later.

-D, --detach-all

Detach all associated loop devices.

-f, --find [file]

Find the first unused loop device. If a file argument is present, use the found device as loop device. Otherwise, just print its name.

--show

Display the name of the assigned loop device if the -f option and a file argument are present.

-L, --nooverlap

Check for conflicts between loop devices to avoid situation when the same backing file is shared between more loop devices. If the file is already used by another device then re-use the device rather than a new one. The option makes sense only with --find.

-j, --associated file [-o offset]

Show the status of all loop devices associated with the given file.

-o, --offset offset

The data start is moved offset bytes into the specified file or device. The offset may be followed by the multiplicative suffixes; see above.

--sizelimit size

The data end is set to no more than size bytes after the data start. The size may be followed by the multiplicative suffixes; see above.

-b, --sector-size size

Set the logical sector size of the loop device in bytes (since Linux 4.14). The option may be used when creating a new loop device as well as a stand-alone command to modify sector size of the already existing loop device.

-c, --set-capacity loopdev

Force the loop driver to reread the size of the file associated with the specified loop device.

-P, --partscan

Force the kernel to scan the partition table on a newly created loop device. Note that the partition table parsing depends on sector sizes. The default is sector size is 512 bytes, otherwise you need to use the option --sector-size together with --partscan.

-r, --read-only

Set up a read-only loop device.

--direct-io[=on|off]

Enable or disable direct I/O for the backing file. The optional argument can be either on or off. If the optional argument is omitted, it defaults to on.

-v, --verbose

Verbose mode.

-l, --list

If a loop device or the -a option is specified, print the default columns for either the specified loop device or all loop devices; the default is to print info about all devices. See also --output, --noheadings, --raw, and --json.

-O, --output column[,column]...

Specify the columns that are to be printed for the --list output. Use --help to get a list of all supported columns.

--output-all

Output all available columns.

-n, --noheadings

Don’t print headings for --list output format.

--raw

Use the raw --list output format.

-J, --json

Use JSON format for --list output.

## ENCRYPTION
Cryptoloop is no longer supported in favor of dm-crypt. For more details see cryptsetup(8).

## EXIT STATUS
losetup returns 0 on success, nonzero on failure. When losetup displays the status of a loop device, it returns 1 if the device is not configured and 2 if an error occurred which prevented determining the status of the device.

## NOTES
Since version 2.37 losetup uses LOOP_CONFIGURE ioctl to setup a new loop device by one ioctl call. The old versions use LOOP_SET_FD and LOOP_SET_STATUS64 ioctls to do the same.

## ENVIRONMENT
LOOPDEV_DEBUG=all

enables debug output.

## FILES
/dev/loop[0..N]

loop block devices

/dev/loop-control

loop control device

## EXAMPLE
The following commands can be used as an example of using the loop device.

```
# dd if=/dev/zero of=~/file.img bs=1024k count=10
# losetup --find --show ~/file.img
/dev/loop0
# mkfs -t ext2 /dev/loop0
# mount /dev/loop0 /mnt
...
# umount /dev/loop0
# losetup --detach /dev/loop0
```

## AUTHORS
Karel Zak <kzak@redhat.com>, based on the original version from Theodore Ts’o <tytso@athena.mit.edu>.

## REPORTING BUGS
For bug reports, use the issue tracker at <https://github.com/util-linux/util-linux/issues>.

## AVAILABILITY
The losetup command is part of the util-linux package which can be downloaded from Linux Kernel Archive <https://www.kernel.org/pub/linux/utils/util-linux/>.