bcc-uflow

title: bcc-uflow(8)

summary: Print a flow graph of method

text:
# bcc-uflow(8)

## NAME
uflow, javaflow, perlflow, phpflow, pythonflow, rubyflow, tclflow - Print a flow graph of method calls in high-level languages.

## SYNOPSIS
javaflow [-h] [-M METHOD] [-C CLAZZ] [-v] pid

perlflow [-h] [-M METHOD] [-C CLAZZ] [-v] pid

phpflow [-h] [-M METHOD] [-C CLAZZ] [-v] pid

pythonflow [-h] [-M METHOD] [-C CLAZZ] [-v] pid

rubyflow [-h] [-M METHOD] [-C CLAZZ] [-v] pid

tclflow [-h] [-M METHOD] [-C CLAZZ] [-v] pid

uflow [-h] [-M METHOD] [-C CLAZZ] [-v] [-l {java,perl,php,python,ruby,tcl}] pid

## DESCRIPTION
uflow traces method calls and prints them in a flow graph that can facilitate debugging and diagnostics by following the program's execution (method flow).

This tool relies on USDT probes embedded in many high-level languages, such as Java, Perl, PHP, Python, Ruby, and Tcl. It requires a runtime instrumented with these probes, which in some cases requires building from source with a USDT-specific flag, such as "--enable-dtrace" or "--with-dtrace". For Java processes, the startup flag "-XX:+ExtendedDTraceProbes" is required. For PHP processes, the environment variable USE_ZEND_DTRACE must be set to 1.

Since this uses BPF, only the root user can use this tool.

## REQUIREMENTS
CONFIG_BPF and bcc.

## OPTIONS
-M METHOD

Print only method calls where the method name begins with this string.

-C CLAZZ

Print only method calls where the class name begins with this string. The class name interpretation strongly depends on the language. For example, in Java use "package/subpackage/ClassName" to refer to classes.

-v

Print the resulting BPF program, for debugging purposes.

{java,perl,php,python,ruby,tcl}

The language to trace.

pid

The process id to trace.

## EXAMPLES
Follow method flow in a Ruby process:

\# uflow ruby 148

Follow method flow in a Java process where the class name is java.lang.Thread:

\# uflow -C java/lang/Thread java 1802

## FIELDS
CPU

The CPU number on which the method was invoked. This is useful to easily see where the output skips to a different CPU.

PID

The process id.

TID

The thread id.

TIME

The duration of the method call.

METHOD

The method name.

## OVERHEAD
This tool has extremely high overhead because it prints every method call. For some scenarios, you might see lost samples in the output as the tool is unable to keep up with the rate of data coming from the kernel. Filtering by class or method prefix can help reduce the amount of data printed, but there is still a very high overhead in the collection mechanism. Do not use for performance- sensitive production scenarios, and always test first.

## SOURCE
This is from bcc.

https://github.com/iovisor/bcc

Also look in the bcc distribution for a companion _example.txt file containing example usage, output, and commentary for this tool.

## OS
Linux

## STABILITY
Unstable - in development.

## AUTHOR
Sasha Goldshtein

## SEE ALSO
trace(8), ustat(8)


bcc-ugc

package: bcc-tools

title: bcc-ugc(8)

summary: Trace garbage collection events in

text:
# bcc-ugc(8)

## NAME
ugc, javagc, nodegc, pythongc, rubygc - Trace garbage collection events in high-level languages.

## SYNOPSIS
javagc [-h] [-v] [-m] [-M MINIMUM] [-F FILTER] pid

nodegc [-h] [-v] [-m] [-M MINIMUM] [-F FILTER] pid

pythongc [-h] [-v] [-m] [-M MINIMUM] [-F FILTER] pid

rubygc [-h] [-v] [-m] [-M MINIMUM] [-F FILTER] pid

ugc [-h] [-v] [-m] [-M MINIMUM] [-F FILTER] [-l {java,node,python,ruby}] pid

## DESCRIPTION
This traces garbage collection events as they occur, including their duration and any additional information (such as generation collected or type of GC) provided by the respective language's runtime.

This tool relies on USDT probes embedded in many high-level languages, such as Java, Node, Python, and Ruby. It requires a runtime instrumented with these probes, which in some cases requires building from source with a USDT-specific flag, such as "--enable-dtrace" or "--with-dtrace".

Since this uses BPF, only the root user can use this tool.

## REQUIREMENTS
CONFIG_BPF and bcc.

## OPTIONS
-v

Print the resulting BPF program, for debugging purposes.

-m

Print times in milliseconds. The default is microseconds.

-M MINIMUM

Display only collections that are longer than this threshold. The value is given in milliseconds. The default is to display all collections.

-F FILTER

Display only collections whose textual description matches (contains) this string. The default is to display all collections. Note that the filtering here is performed in user-space, and not as part of the BPF program. This means that if you have thousands of collection events, specifying this filter will not reduce the amount of data that has to be transferred from the BPF program to the user-space script.

{java,node,python,ruby}

The language to trace.

pid

The process id to trace.

## EXAMPLES
Trace garbage collections in a specific Node process:

\# ugc node 148

Trace garbage collections in a specific Java process, and print GC times in

milliseconds: # ugc -m java 6004

Trace garbage collections in a specific Java process, and display them only if

they are longer than 10ms and have the string "Tenured" in their detailed description: # ugc -M 10 -F Tenured java 6004

## FIELDS
START

The start time of the GC, in seconds from the beginning of the trace.

TIME

The duration of the garbage collection event.

DESCRIPTION

The runtime-provided description of this garbage collection event.

## OVERHEAD
Garbage collection events, even if frequent, should not produce a considerable overhead when traced because they are still not very common. Even hundreds of GCs per second (which is a very high rate) will still produce a fairly negligible overhead.

## SOURCE
This is from bcc.

https://github.com/iovisor/bcc

Also look in the bcc distribution for a companion _example.txt file containing example usage, output, and commentary for this tool.

## OS
Linux

## STABILITY
Unstable - in development.

## AUTHOR
Sasha Goldshtein

## SEE ALSO
trace(8), ustat(8), uobjnew(8)


bcc-uobjnew

title: bcc-uobjnew(8)

summary: Summarize object allocations in

text:
# bcc-uobjnew(8)

## NAME
uobjnew, cobjnew, javaobjnew, rubyobjnew, tclobjnew - Summarize object allocations in high-level languages.

## SYNOPSIS
cobjnew [-h] [-C TOP_COUNT] [-S TOP_SIZE] [-v] pid [interval]

javaobjnew [-h] [-C TOP_COUNT] [-S TOP_SIZE] [-v] pid [interval]

rubyobjnew [-h] [-C TOP_COUNT] [-S TOP_SIZE] [-v] pid [interval]

tclobjnew [-h] [-C TOP_COUNT] [-S TOP_SIZE] [-v] pid [interval]

uobjnew [-h] [-C TOP_COUNT] [-S TOP_SIZE] [-v] [-l {c,java,ruby,tcl}] pid [interval]

## DESCRIPTION
uobjnew traces object allocations in high-level languages (including "malloc") and prints summaries of the most frequently allocated types by number of objects or number of bytes.

This tool relies on USDT probes embedded in many high-level languages, such as C, Java, Ruby, and Tcl. It requires a runtime instrumented with these probes, which in some cases requires building from source with a USDT-specific flag, such as "--enable-dtrace" or "--with-dtrace". For Java, the Java process must be started with the "-XX:+ExtendedDTraceProbes" flag.

Since this uses BPF, only the root user can use this tool.

## REQUIREMENTS
CONFIG_BPF and bcc.

## OPTIONS
-C TOP_COUNT

Print the top object types sorted by number of instances.

-S TOP_SIZE

Print the top object types sorted by size.

-v

Print the resulting BPF program, for debugging purposes.

{c,java,ruby,tcl}

The language to trace.

pid

The process id to trace.

interval

Wait this many seconds and then print the summary and exit. By default, wait for Ctrl+C to exit.

## EXAMPLES
Trace object allocations in a Ruby process:

\# uobjnew ruby 148

Trace object allocations from "malloc" and print the top 10 by total size:

\# uobjnew -S 10 c 1788

## FIELDS
TYPE

The object type being allocated. For C (malloc), this is the block size.

ALLOCS

The number of objects allocated.

BYTES

The number of bytes allocated.

## OVERHEAD
Object allocation events are quite frequent, and therefore the overhead from running this tool can be considerable. Use with caution and make sure to test before using in a production environment. Nonetheless, even thousands of allocations per second will likely produce a reasonable overhead when investigating a problem.

## SOURCE
This is from bcc.

https://github.com/iovisor/bcc

Also look in the bcc distribution for a companion _example.txt file containing example usage, output, and commentary for this tool.

## OS
Linux

## STABILITY
Unstable - in development.

## AUTHOR
Sasha Goldshtein

## SEE ALSO
ustat(8), ugc(8), memleak(8)


bcc-ustat

title: bcc-ustat(8)

summary: Activity stats from

text:
# bcc-ustat(8)

## NAME
ustat, javastat, nodestat, perlstat, phpstat, pythonstat, rubystat, tclstat - Activity stats from high-level languages.

## SYNOPSIS
javastat [-C] [-S {cload,excp,gc,method,objnew,thread}] [-r MAXROWS] [-d] [interval [count]]

nodestat [-C] [-S {cload,excp,gc,method,objnew,thread}] [-r MAXROWS] [-d] [interval [count]]

perlstat [-C] [-S {cload,excp,gc,method,objnew,thread}] [-r MAXROWS] [-d] [interval [count]]

phpstat [-C] [-S {cload,excp,gc,method,objnew,thread}] [-r MAXROWS] [-d] [interval [count]]

pythonstat [-C] [-S {cload,excp,gc,method,objnew,thread}] [-r MAXROWS] [-d] [interval [count]]

rubystat [-C] [-S {cload,excp,gc,method,objnew,thread}] [-r MAXROWS] [-d] [interval [count]]

tclstat [-C] [-S {cload,excp,gc,method,objnew,thread}] [-r MAXROWS] [-d] [interval [count]]

ustat [-l {java,node,perl,php,python,ruby,tcl}] [-C] [-S {cload,excp,gc,method,objnew,thread}] [-r MAXROWS] [-d] [interval [count]]

## DESCRIPTION
This is "top" for high-level language events, such as garbage collections, exceptions, thread creations, object allocations, method calls, and more. The events are aggregated for each process and printed in a top-like table, which can be sorted by various fields. Not all language runtimes provide the same set of details.

This uses in-kernel eBPF maps to store per process summaries for efficiency.

This tool relies on USDT probes embedded in many high-level languages, such as Java, Node, Perl, PHP, Python, Ruby, and Tcl. It requires a runtime instrumented with these probes, which in some cases requires building from source with a USDT-specific flag, such as "--enable-dtrace" or "--with-dtrace". For Java, some probes are not enabled by default, and can be turned on by running the Java process with the "-XX:+ExtendedDTraceProbes" flag. For PHP processes, the environment variable USE_ZEND_DTRACE must be set to 1.

Newly-created processes will only be traced at the next interval. If you run this tool with a short interval (say, 1-5 seconds), this should be virtually unnoticeable. For longer intervals, you might miss processes that were started and terminated during the interval window.

Since this uses BPF, only the root user can use this tool.

## REQUIREMENTS
CONFIG_BPF and bcc.

## OPTIONS
-l {java,node,perl,php,python,ruby,tcl}

The language to trace. By default, all languages are traced.

-C

Do not clear the screen between updates.

-S {cload,excp,gc,method,objnew,thread}

Sort the output by the specified field.

-r MAXROWS

Do not print more than this number of rows.

-d

Print the resulting BPF program, for debugging purposes.

interval

Interval between updates, seconds.

count

Number of interval summaries.

## EXAMPLES
Summarize activity in high-level languages, 1 second refresh:

\# ustat

Don't clear the screen, and top 8 rows only:

\# ustat -Cr 8

5 second summaries, 10 times only:

\# ustat 5 10

## FIELDS
loadavg

The contents of /proc/loadavg

PID

Process ID.

CMDLINE

Process command line (often the second and following arguments will give you a hint as to which application is being run.

METHOD/s

Count of method invocations during interval.

GC/s

Count of garbage collections during interval.

OBJNEW/s

Count of objects allocated during interval.

CLOAD/s

Count of classes loaded during interval.

EXC/s

Count of exceptions thrown during interval.

THR/s

Count of threads created during interval.

## OVERHEAD
When using this tool with high-frequency events, such as method calls, a very significant slow-down can be expected. However, many of the high-level languages covered by this tool already have a fairly high per-method invocation cost, especially when running in interpreted mode. For the lower-frequency events, such as garbage collections or thread creations, the overhead should not be significant. Specifically, when probing Java processes and not using the "-XX:+ExtendedDTraceProbes" flag, the most expensive probes are not emitted, and the overhead should be acceptable.

## SOURCE
This is from bcc.

https://github.com/iovisor/bcc

Also look in the bcc distribution for a companion _example.txt file containing example usage, output, and commentary for this tool.

## OS
Linux

## STABILITY
Unstable - in development.

## AUTHOR
Sasha Goldshtein

## SEE ALSO
trace(8), argdist(8), tplist(8)


bcc-uthreads

title: bcc-uthreads(8)

text:
# bcc-uthreads(8)

## NAME
uthreads, cthreads, javathreads - Trace thread creation events in Java or pthreads.

## SYNOPSIS
cthreads [-h] [-v] pid javathreads [-h] [-v] pid uthreads [-h] [-l {c,java,none}] [-v] pid

## DESCRIPTION
This traces thread creation events in Java processes, or pthread creation events in any process. When a thread is created, its name or start address is printed.

Since this uses BPF, only the root user can use this tool.

## REQUIREMENTS
CONFIG_BPF and bcc.

## OPTIONS
-l {c,java,none}

The language to trace. C and none select tracing pthreads only, regardless of the runtime being traced.

-v

Print the resulting BPF program, for debugging purposes.

pid

The process id to trace.

## EXAMPLES
Trace Java thread creations:

\# uthreads -l java 148

Trace pthread creations:

\# uthreads 1802

## FIELDS
TIME

The event's time in seconds from the beginning of the trace.

ID

The thread's ID. The information in this column depends on the runtime.

TYPE

Event type -- thread start, stop, or pthread event.

DESCRIPTION

The thread's name or start address function name.

## OVERHEAD
Thread start and stop events are usually not very frequent, which makes this tool's overhead negligible.

## SOURCE
This is from bcc.

https://github.com/iovisor/bcc

Also look in the bcc distribution for a companion _example.txt file containing example usage, output, and commentary for this tool.

## OS
Linux

## STABILITY
Unstable - in development.

## AUTHOR
Sasha Goldshtein

## SEE ALSO
ustat(8), trace(8)


bcc-vfscount

title: bcc-vfscount(8)

summary: Count VFS calls (vfs_*). Uses Linux eBPF/bcc.

text:
# bcc-vfscount(8)

## NAME
vfscount - Count VFS calls ("vfs_*"). Uses Linux eBPF/bcc.

## SYNOPSIS
vfscount [duration]

## DESCRIPTION
This counts VFS calls. This can be useful for general workload characterization of these operations.

This works by tracing all kernel functions beginning with "vfs_" using dynamic tracing. This may match more functions than you are interested in measuring: Edit the script to customize which functions to trace.

Since this uses BPF, only the root user can use this tool.

## REQUIREMENTS
CONFIG_BPF and bcc.

## OPTIONS
duration

duration of the trace in seconds.

## EXAMPLES
Count some VFS calls until Ctrl-C is hit:

\# vfscount

Count some VFS calls in ten seconds

\# vfscount 10

## FIELDS
ADDR

Address of the instruction pointer that was traced (only useful if the FUNC column is suspicious and you would like to double check the translation).

FUNC

Kernel function name

COUNT

Number of calls while tracing

## OVERHEAD
This traces kernel vfs functions and maintains in-kernel counts, which are asynchronously copied to user-space. While the rate of VFS operations can be very high (>1M/sec), this is a relatively efficient way to trace these events, and so the overhead is expected to be small for normal workloads. Measure in a test environment, and if overheads are an issue, edit the script to reduce the types of vfs functions traced (currently all beginning with "vfs_").

## SOURCE
This is from bcc.

https://github.com/iovisor/bcc

Also look in the bcc distribution for a companion _examples.txt file containing example usage, output, and commentary for this tool.

## OS
Linux

## STABILITY
Unstable - in development.

## AUTHOR
Brendan Gregg

## SEE ALSO
vfsstat(8)


bcc-vfsstat

title: bcc-vfsstat(8)

text:
# bcc-vfsstat(8)

## NAME
vfsstat - Statistics for some common VFS calls. Uses Linux eBPF/bcc.

## SYNOPSIS
vfsstat [interval [count]]

## DESCRIPTION
This traces some common VFS calls and prints per-second summaries. This can be useful for general workload characterization, and looking for patterns in operation usage over time.

This works by tracing some kernel vfs functions using dynamic tracing, and will need updating to match any changes to these functions. Edit the script to customize which functions are traced. Also see vfscount, which is more easily customized to trace multiple functions.

Since this uses BPF, only the root user can use this tool.

## REQUIREMENTS
CONFIG_BPF and bcc.

## EXAMPLES
Print summaries each second:

\# vfsstat

Print output every five seconds, three times:

\# vfsstat 5 3

## FIELDS
READ/s

Number of vfs_read() calls as a per-second average.

WRITE/s

Number of vfs_write() calls as a per-second average.

CREATE/s

Number of vfs_create() calls as a per-second average.

OPEN/s

Number of vfs_open() calls as a per-second average.

FSYNC/s

Number of vfs_fsync() calls as a per-second average.

## OVERHEAD
This traces various kernel vfs functions and maintains in-kernel counts, which are asynchronously copied to user-space. While the rate of VFS operations can be very high (>1M/sec), this is a relatively efficient way to trace these events, and so the overhead is expected to be small for normal workloads. Measure in a test environment.

## SOURCE
This is from bcc.

https://github.com/iovisor/bcc

Also look in the bcc distribution for a companion _examples.txt file containing example usage, output, and commentary for this tool.

## OS
Linux

## STABILITY
Unstable - in development.

## AUTHOR
Brendan Gregg

## SEE ALSO
vfscount(8)


bcc-virtiostat

title: bcc-virtiostat(8)

text:
# bcc-virtiostat(8)

## NAME
virtiostat - Trace VIRTIO devices input/output statistics. Uses Linux eBPF/bcc.

## SYNOPSIS
virtiostat [-h] [-T] [-D] [-d DRIVER] [-n DEVNAME] [INTERVAL] [COUNT]

## DESCRIPTION
This tool traces VIRTIO devices input/output statistics. It works in lower layer of VIRTIO base driver, so it could trace all the devices of VIRTIO family. For example, we can't get IO statistics of 9p-fs in a guest virtual machine by iostat command, but we can analyze IO statistics by virtiostat. The outputing result shows In/Out SGs(scatter list operation) to represent positive correlation IOPS, and In/Out BW to represent throughput.

Since this uses BPF, only the root user can use this tool.

## REQUIREMENTS
CONFIG_BPF and bcc.

## OPTIONS
-h

Print usage message.

-T

Include a time column on output (HH:MM:SS).

-D

Show debug infomation of bpf text.

-d DRIVER

Filter for driver name.

-n DEVNAME

Filter for device name.

INTERVAL

Print output every interval seconds.

COUNT

Total count of trace in seconds.

## EXAMPLES
Trace virtio device statistics and print 1 second summaries, 10 times:

\# virtiostat 1 10

Trace virtio block deivces only:

\# virtiostat -d virtio_blk

## OVERHEAD
This traces the kernel virtqueue_add_sgs, virtqueue_add_outbuf, virtqueue_add_inbuf, virtqueue_add_inbuf_ctx functions. The rate of this depends on all the VIRTIO devices IOPS.

## SOURCE
This is from bcc.

https://github.com/iovisor/bcc

Also look in the bcc distribution for a companion _examples.txt file containing example usage, output, and commentary for this tool.

## OS
Linux

## STABILITY
Unstable - in development.

## AUTHOR
zhenwei pi

## SEE ALSO
iostat(1), iftop(8), funccount(8)


bcc-wakeuptime

title: bcc-wakeuptime(8)

text:
# bcc-wakeuptime(8)

## NAME
wakeuptime - Summarize sleep to wakeup time by waker kernel stack. Uses Linux eBPF/bcc.

## SYNOPSIS
wakeuptime [-h] [-u] [-p PID] [-v] [-f] [--stack-storage-size STACK_STORAGE_SIZE] [-m MIN_BLOCK_TIME] [-M MAX_BLOCK_TIME] [duration]

## DESCRIPTION
This program shows the kernel stack traces for threads that woke up other blocked threads, along with the process names of the waker and target, along with a sum of the time that the target was blocked: the "blocked time". It works by tracing when threads block and when they were then woken up, and measuring the time delta. This time measurement will be very similar to off-CPU time, however, off-CPU time may include a little extra time spent waiting on a run queue to be scheduled. The stack traces, process names, and time spent blocked is summarized in the kernel using an eBPF map for efficiency.

The output summary will help you identify reasons why threads were blocking by showing who woke them up, along with the time they were blocked. This spans all types of blocking activity: disk I/O, network I/O, locks, page faults, involuntary context switches, etc.

This can be used in conjunction with offcputime, which shows the stack trace of the blocked thread. wakeuptime shows the stack trace of the waker thread.

See http://www.brendangregg.com/FlameGraphs/offcpuflamegraphs.html

This tool only works on Linux 4.6+. It uses the new `BPF_STACK_TRACE` table APIs to generate the in-kernel stack traces.

## REQUIREMENTS
CONFIG_BPF and bcc.

## OPTIONS
-h

Print usage message.

-f

Print output in folded stack format.

-u

Only trace user threads (not kernel threads).

-v

Show raw addresses (for non-folded format).

-p PID

Trace this process ID only (filtered in-kernel).

--stack-storage-size STACK_STORAGE_SIZE

Change the number of unique stack traces that can be stored and displayed.

duration

Duration to trace, in seconds.

-m MIN_BLOCK_TIME

The amount of time in microseconds over which we store traces (default 1)

-M MAX_BLOCK_TIME

The amount of time in microseconds under which we store traces (default U64_MAX)

## EXAMPLES
Trace all thread blocking events, and summarize (in-kernel) by kernel stack trace and total blocked time:

\# wakeuptime

Trace user-mode target threads only:

\# wakeuptime -u

Trace for 5 seconds only:

\# wakeuptime 5

Trace for 5 seconds, and emit output in folded stack format (suitable for flame graphs):

\# wakeuptime -f 5

Trace PID 185 only:

\# wakeuptime -p 185

## OVERHEAD
This summarizes unique stack traces in-kernel for efficiency, allowing it to trace a higher rate of events than methods that post-process in user space. The stack trace and time data is only copied to user space once, when the output is printed. While these techniques greatly lower overhead, scheduler events are still a high frequency event, as they can exceed 1 million events per second, and so caution should still be used. Test before production use.

If the overhead is still a problem, take a look at the min block option. If your aim is to chase down longer blocking events, then this could be increased to filter shorter blocking events, further lowering overhead.

## SOURCE
This is from bcc.

https://github.com/iovisor/bcc

Also look in the bcc distribution for a companion _examples.txt file containing example usage, output, and commentary for this tool.

## OS
Linux

## STABILITY
Unstable - in development.

## AUTHOR
Brendan Gregg

## SEE ALSO
offcputime(8), stackcount(8)


bcc-wqlat

title: bcc-wqlat(8)

text:
# bcc-wqlat(8)

## NAME
wqlat - Summarize kernel workqueue latency as a histogram.

## SYNOPSIS
wqlat [-h] [-T] [-N] [-W] [-w WQNAME] [interval [count]]

## DESCRIPTION
wqlat traces work's waiting on workqueue, and records the distribution of work's queuing latency (time). This is printed as a histogram either on Ctrl-C, or after a given interval in seconds.

This tool uses in-kernel eBPF maps for storing timestamps and the histogram, for efficiency.

This tool uses the workqueue:workqueue_queue_work and workqueue:workqueue_execute_start kernel tracepoints, which is a stable tracing mechanism. Please note BPF programs can attach to tracepoints from Linux 4.7 only, so this tools can only support kernel 4.7 or later version.

Since this uses BPF, only the root user can use this tool.

## REQUIREMENTS
CONFIG_BPF and bcc.

## OPTIONS
-h Print usage message.

-T

Include timestamps on output.

-N

Output histogram in nanoseconds.

-W

Print a histogram per workqueue.

-w WQNAME

Trace this workqueue only

interval

Output interval, in seconds.

count

Number of outputs.

## EXAMPLES
Summarize kernel workqueue latency as a histogram:

\# wqlat

Print 1 second summaries, 10 times:

\# wqlat 1 10

Print 1 second summaries, using nanoseconds as units for the histogram, and

include timestamps on output: # wqlat -NT 1

Print 1 second summaries, 10 times per workqueue:

\# wqlat -W 1 10

Print 1 second summaries for workqueue nvmet_tcp_wq:

\# wqlat -w nvmet_tcp_wq 1

## FIELDS
usecs

Microsecond range

nsecs

Nanosecond range

count

How many works into this range

distribution

An ASCII bar chart to visualize the distribution (count column)

## OVERHEAD
This traces kernel functions and maintains in-kernel timestamps and a histogram, which are asynchronously copied to user-space. This method is very efficient, and the overhead for most workqueue scheduling rates (< 100k) should be negligible.If you have a higher workqueue scheduling, please test and quantify the overhead before use.

## SOURCE
This is from bcc.

https://github.com/iovisor/bcc

Also look in the bcc distribution for a companion _examples.txt file containing example usage, output, and commentary for this tool.

## OS
Linux

## STABILITY
Unstable - in development.

## AUTHOR
Ping Gan

## SEE ALSO
biolatency


bcc-xfsdist

title: bcc-xfsdist(8)

text:
# bcc-xfsdist(8)

## NAME
xfsdist - Summarize XFS operation latency. Uses Linux eBPF/bcc.

## SYNOPSIS
xfsdist [-h] [-T] [-m] [-p PID] [interval] [count]

## DESCRIPTION
This tool summarizes time (latency) spent in common XFS file operations: reads, writes, opens, and syncs, and presents it as a power-of-2 histogram. It uses an in-kernel eBPF map to store the histogram for efficiency.

Since this works by tracing the xfs_file_operations interface functions, it will need updating to match any changes to these functions.

Since this uses BPF, only the root user can use this tool.

## REQUIREMENTS
CONFIG_BPF and bcc.

## OPTIONS
-h

Print usage message.

-T

Don't include timestamps on interval output.

-m

Output in milliseconds.

-p PID

Trace this PID only.

## EXAMPLES
Trace XFS operation time, and print a summary on Ctrl-C:

\# xfsdist

Trace PID 181 only:

\# xfsdist -p 181

Print 1 second summaries, 10 times:

\# xfsdist 1 10

1 second summaries, printed in milliseconds

\# xfsdist -m 1

## FIELDS
msecs

Range of milliseconds for this bucket.

usecs

Range of microseconds for this bucket.

count

Number of operations in this time range.

distribution

ASCII representation of the distribution (the count column).

## OVERHEAD
This adds low-overhead instrumentation to these XFS operations, including reads and writes from the file system cache. Such reads and writes can be very frequent (depending on the workload; eg, 1M/sec), at which point the overhead of this tool may become noticeable. Measure and quantify before use.

## SOURCE
This is from bcc.

https://github.com/iovisor/bcc

Also look in the bcc distribution for a companion _examples.txt file containing example usage, output, and commentary for this tool.

## OS
Linux

## STABILITY
Unstable - in development.

## AUTHOR
Brendan Gregg

## SEE ALSO
xfssnoop(8)


bcc-xfsslower

title: bcc-xfsslower(8)

text:
# bcc-xfsslower(8)

## NAME
xfsslower - Trace slow xfs file operations, with per-event details.

## SYNOPSIS
xfsslower [-h] [-j] [-p PID] [min_ms]

## DESCRIPTION
This tool traces common XFS file operations: reads, writes, opens, and syncs. It measures the time spent in these operations, and prints details for each that exceeded a threshold.

WARNING: See the OVERHEAD section.

By default, a minimum millisecond threshold of 10 is used. If a threshold of 0 is used, all events are printed (warning: verbose).

Since this works by tracing the xfs_file_operations interface functions, it will need updating to match any changes to these functions.

Since this uses BPF, only the root user can use this tool.

## REQUIREMENTS
CONFIG_BPF and bcc.

## OPTIONS
-p PID Trace this PID only.

min_ms

Minimum I/O latency (duration) to trace, in milliseconds. Default is 10 ms.

## EXAMPLES
Trace synchronous file reads and writes slower than 10 ms:

\# xfsslower

Trace slower than 1 ms:

\# xfsslower 1

Trace slower than 1 ms, and output just the fields in parsable format (csv):

\# xfsslower -j 1

Trace all file reads and writes (warning: the output will be verbose):

\# xfsslower 0

Trace slower than 1 ms, for PID 181 only:

\# xfsslower -p 181 1

## FIELDS
TIME(s)

Time of I/O completion since the first I/O seen, in seconds.

COMM

Process name.

PID

Process ID.

T

Type of operation. R == read, W == write, O == open, S == fsync.

OFF_KB

File offset for the I/O, in Kbytes.

BYTES

Size of I/O, in bytes.

LAT(ms)

Latency (duration) of I/O, measured from when it was issued by VFS to the filesystem, to when it completed. This time is inclusive of block device I/O, file system CPU cycles, file system locks, run queue latency, etc. It's a more accurate measure of the latency suffered by applications performing file system I/O, than to measure this down at the block device interface.

FILENAME

A cached kernel file name (comes from dentry->d_name.name).

ENDTIME_us

Completion timestamp, microseconds (-j only).

OFFSET_b

File offset, bytes (-j only).

LATENCY_us

Latency (duration) of the I/O, in microseconds (-j only).

## OVERHEAD
This adds low-overhead instrumentation to these XFS operations, including reads and writes from the file system cache. Such reads and writes can be very frequent (depending on the workload; eg, 1M/sec), at which point the overhead of this tool (even if it prints no "slower" events) can begin to become significant. Measure and quantify before use. If this continues to be a problem, consider switching to a tool that prints in-kernel summaries only.

Note that the overhead of this tool should be less than fileslower(8), as this tool targets xfs functions only, and not all file read/write paths (which can include socket I/O).

## SOURCE
This is from bcc.

https://github.com/iovisor/bcc

Also look in the bcc distribution for a companion _examples.txt file containing example usage, output, and commentary for this tool.

## OS
Linux

## STABILITY
Unstable - in development.

## AUTHOR
Brendan Gregg

## SEE ALSO
biosnoop(8), funccount(8), fileslower(8)


bcc-zfsdist

title: bcc-zfsdist(8)

text:
# bcc-zfsdist(8)

## NAME
zfsdist - Summarize ZFS operation latency. Uses Linux eBPF/bcc.

## SYNOPSIS
zfsdist [-h] [-T] [-m] [-p PID] [interval] [count]

## DESCRIPTION
This tool summarizes time (latency) spent in common ZFS file operations: reads, writes, opens, and syncs, and presents it as a power-of-2 histogram. It uses an in-kernel eBPF map to store the histogram for efficiency.

This uses kernel dynamic tracing of the ZPL interface (ZFS POSIX Layer), and will need updates to match any changes to this interface.

This is intended to work with the ZFS on Linux project:

http://zfsonlinux.org

Since this uses BPF, only the root user can use this tool.

## REQUIREMENTS
CONFIG_BPF and bcc.

## OPTIONS
-h

Print usage message.

-T

Don't include timestamps on interval output.

-m

Output in milliseconds.

-p PID

Trace this PID only.

## EXAMPLES
Trace ZFS operation time, and print a summary on Ctrl-C:

\# zfsdist

Trace PID 181 only:

\# zfsdist -p 181

Print 1 second summaries, 10 times:

\# zfsdist 1 10

1 second summaries, printed in milliseconds

\# zfsdist -m 1

## FIELDS
msecs

Range of milliseconds for this bucket.

usecs

Range of microseconds for this bucket.

count

Number of operations in this time range.

distribution

ASCII representation of the distribution (the count column).

## OVERHEAD
This adds low-overhead instrumentation to these ZFS operations, including reads and writes from the file system cache. Such reads and writes can be very frequent (depending on the workload; eg, 1M/sec), at which point the overhead of this tool may become noticeable. Measure and quantify before use.

## SOURCE
This is from bcc.

https://github.com/iovisor/bcc

Also look in the bcc distribution for a companion _examples.txt file containing example usage, output, and commentary for this tool.

## OS
Linux

## STABILITY
Unstable - in development.

## AUTHOR
Brendan Gregg

## SEE ALSO
zfssnoop(8)


bcc-zfsslower

title: bcc-zfsslower(8)

text:
# bcc-zfsslower(8)

## NAME
zfsslower - Trace slow zfs file operations, with per-event details.

## SYNOPSIS
zfsslower [-h] [-j] [-p PID] [min_ms]

## DESCRIPTION
This tool traces common ZFS file operations: reads, writes, opens, and syncs. It measures the time spent in these operations, and prints details for each that exceeded a threshold.

WARNING: See the OVERHEAD section.

By default, a minimum millisecond threshold of 10 is used. If a threshold of 0 is used, all events are printed (warning: verbose).

This uses kernel dynamic tracing of the ZPL interface (ZFS POSIX Layer), and will need updates to match any changes to this interface.

This is intended to work with the ZFS on Linux project:

http://zfsonlinux.org

Since this uses BPF, only the root user can use this tool.

## REQUIREMENTS
CONFIG_BPF and bcc.

## OPTIONS
-p PID Trace this PID only.

min_ms

Minimum I/O latency (duration) to trace, in milliseconds. Default is 10 ms.

## EXAMPLES
Trace synchronous file reads and writes slower than 10 ms:

\# zfsslower

Trace slower than 1 ms:

\# zfsslower 1

Trace slower than 1 ms, and output just the fields in parsable format (csv):

\# zfsslower -j 1

Trace all file reads and writes (warning: the output will be verbose):

\# zfsslower 0

Trace slower than 1 ms, for PID 181 only:

\# zfsslower -p 181 1

## FIELDS
TIME(s)

Time of I/O completion since the first I/O seen, in seconds.

COMM

Process name.

PID

Process ID.

T

Type of operation. R == read, W == write, O == open, S == fsync.

OFF_KB

File offset for the I/O, in Kbytes.

BYTES

Size of I/O, in bytes.

LAT(ms)

Latency (duration) of I/O, measured from when it was issued by VFS to the filesystem, to when it completed. This time is inclusive of block device I/O, file system CPU cycles, file system locks, run queue latency, etc. It's a more accurate measure of the latency suffered by applications performing file system I/O, than to measure this down at the block device interface.

FILENAME

A cached kernel file name (comes from dentry->d_name.name).

ENDTIME_us

Completion timestamp, microseconds (-j only).

OFFSET_b

File offset, bytes (-j only).

LATENCY_us

Latency (duration) of the I/O, in microseconds (-j only).

## OVERHEAD
This adds low-overhead instrumentation to these ZFS operations, including reads and writes from the file system cache. Such reads and writes can be very frequent (depending on the workload; eg, 1M/sec), at which point the overhead of this tool (even if it prints no "slower" events) can begin to become significant. Measure and quantify before use. If this continues to be a problem, consider switching to a tool that prints in-kernel summaries only.

Note that the overhead of this tool should be less than fileslower(8), as this tool targets zfs functions only, and not all file read/write paths (which can include socket I/O).

## SOURCE
This is from bcc.

https://github.com/iovisor/bcc

Also look in the bcc distribution for a companion _examples.txt file containing example usage, output, and commentary for this tool.

## OS
Linux

## STABILITY
Unstable - in development.

## AUTHOR
Brendan Gregg

## SEE ALSO
biosnoop(8), funccount(8), fileslower(8)


title: bgpq3(8)

text:
# bgpq3(8)

## NAME
bgpq3 — bgp filtering automation for cisco and juniper routers

## SYNOPSIS
bgpq3

[-h host] [-S sources] [-EP] [-f asn | -G asn] [-346AbDdJjX] [-r len] [-R len] [-m max] [-W len] OBJECTS [...]

## DESCRIPTION
The bgpq3 utility used to generate Cisco and Juniper prefix-lists, extended access-lists, policy-statement terms and as-path lists based on RADB data.

The options are as follows:

-3

assume that your device is asn32-safe.

-4

generate IPv4 prefix/access-lists (default).

-6

generate IPv6 prefix/access-lists (IPv4 by default).

-A

try to aggregate prefix-lists as much as possible (not all output formats supported).

-b

generate output in BIRD format (default: Cisco).

-d

enable some debugging output.

-D

use asdot notation for Cisco as-path access-lists.

-E

generate extended access-list (Cisco) or policy-statement term using route-filters (Juniper).

-f number

generate input as-path access-list.

-G number

generate output as-path access-list.

-h host

host running IRRD database (default: whois.radb.net).

-J

generate config for Juniper (default: Cisco).

-j

generate output in JSON format (default: Cisco).

-m len

maximum prefix-length of accepted prefixes (default: 32 for IPv4 and 128 for IPv6).

-M match

extra match conditions for Juniper route-filters.

-l name

name of generated entry.

-P

generate prefix-list (default, backward compatibility).

-r len

allow more specific routes starting with specified masklen too.

-R len

allow more specific routes up to specified masklen too.

-S sources

use specified sources only (default: RADB,RIPE,APNIC).

-T

disable pipelining.

-W len

generate as-path strings of no more than len items (use 0 for inifinity).

-X

generate config for Cisco IOS XR devices (plain IOS by default).

OBJECTS

means networks (in prefix format), autonomous systems, as-sets and route-sets.

## EXAMPLES
Generating named juniper prefix-filter for AS20597:

```
~>bgpq3 -Jl eltel AS20597
policy-options {
replace:
 prefix-list eltel {
    81.9.0.0/20;
    81.9.32.0/20;
    81.9.96.0/20;
    81.222.128.0/20;
    81.222.192.0/18;
    85.249.8.0/21;
    85.249.224.0/19;
    89.112.0.0/19;
    89.112.4.0/22;
    89.112.32.0/19;
    89.112.64.0/19;
    217.170.64.0/20;
    217.170.80.0/20;
 }
}
```

For Cisco we can use aggregation (-A) flag to make this prefix-filter more compact:

```
~>bgpq3 -Al eltel AS20597
no ip prefix-list eltel
ip prefix-list eltel permit 81.9.0.0/20
ip prefix-list eltel permit 81.9.32.0/20
ip prefix-list eltel permit 81.9.96.0/20
ip prefix-list eltel permit 81.222.128.0/20
ip prefix-list eltel permit 81.222.192.0/18
ip prefix-list eltel permit 85.249.8.0/21
ip prefix-list eltel permit 85.249.224.0/19
ip prefix-list eltel permit 89.112.0.0/18 ge 19 le 19
ip prefix-list eltel permit 89.112.4.0/22
ip prefix-list eltel permit 89.112.64.0/19
ip prefix-list eltel permit 217.170.64.0/19 ge 20 le 20
```

- you see, prefixes 89.112.0.0/19 and 89.112.32.0/19 now aggregated into single entry 89.112.0.0/18 ge 19 le 19.

Well, for Juniper we can generate even more interesting policy-options, using -M <extra match conditions>, -R <len> and hierarchical names:

```
policy-options {
 policy-statement eltel {
  term specifics {
replace:
   from {
    community blackhole;
    route-filter 81.9.0.0/20 prefix-length-range /29-/32;
    route-filter 81.9.32.0/20 prefix-length-range /29-/32;
    route-filter 81.9.96.0/20 prefix-length-range /29-/32;
    route-filter 81.222.128.0/20 prefix-length-range /29-/32;
    route-filter 81.222.192.0/18 prefix-length-range /29-/32;
    route-filter 85.249.8.0/21 prefix-length-range /29-/32;
    route-filter 85.249.224.0/19 prefix-length-range /29-/32;
    route-filter 89.112.0.0/17 prefix-length-range /29-/32;
    route-filter 217.170.64.0/19 prefix-length-range /29-/32;
   }
  }
 }
}
```

generated policy-option term now allows all specifics with prefix-length between /29 and /32 for eltel networks if they match with special community Of course, this version supports IPv6 (-6):

```
~>bgpq3 -6l as-retn-6 AS-RETN6
no ipv6 prefix-list as-retn-6
ipv6 prefix-list as-retn-6 permit 2001:7fb:fe00::/48
ipv6 prefix-list as-retn-6 permit 2001:7fb:fe01::/48
[....]
```

and support for ASN 32 is also here

```
~>bgpq3 -J3f 112 AS-SPACENET
policy-options {
replace:
 as-path-group NN {
  as-path a0 "^112(112)*$";
  as-path a1 "^112(.)*(1898|5539|8495|8763|8878|12136|12931|15909)$";
  as-path a2 "^112(.)*(21358|23456|23600|24151|25152|31529|34127|34906)$";
  as-path a3 "^112(.)*(35052|41720|43628|44450|196611)$";
 }
}
```

see AS196611 in the end of the list ? That's AS3.3 in 'asplain' notation.

For non-ASN32 capable routers you should not use switch -3, and the result will be next:

```
~>bgpq3 -f 112 AS-SPACENET
no ip as-path access-list NN
ip as-path access-list NN permit ^112(_112)*$
ip as-path access-list NN permit ^112(_[0-9]+)*_(1898|5539|8495|8763)$
ip as-path access-list NN permit ^112(_[0-9]+)*_(8878|12136|12931|15909)$
ip as-path access-list NN permit ^112(_[0-9]+)*_(21358|23456|23600|24151)$
ip as-path access-list NN permit ^112(_[0-9]+)*_(25152|31529|34127|34906)$
ip as-path access-list NN permit ^112(_[0-9]+)*_(35052|41720|43628|44450)$
```

AS196611 is no more in the list, however, AS23456 (transition AS) would be added to list if it were not present.

## DIAGNOSTICS
When everything is OK, bgpq3 generates access-list to standard output and exits with status == 0. In case of errors they are printed to stderr and program exits with non-zero status.

## SEE ALSO
http://www.radb.net/ Routing Arbiter project http://tools.ietf.org/html/draft-michaelson-4byte-as-representation-05 for information on 'asdot' and 'asplain' notations. http://www.cisco.com/en/US/docs/ios/12_0s/release/ntes/120SNEWF.html#wp3521658 for information on Cisco implementation of ASN32.

## AUTHOR
Alexandre Snarskii ⟨snar@snar.spb.ru⟩


ddns-confgen

package: bind

title: ddns-confgen(8)

summary: ddns key generation tool

text:
# ddns-confgen(8)

## NAME
ddns-confgen - ddns key generation tool

## SYNOPSIS
ddns-confgen [-a algorithm] [-h] [-k keyname] [-q] [-s name] [-z zone]

## DESCRIPTION
ddns-confgen is an utility that generates keys for use in TSIG signing. The resulting keys can be used, for example, to secure dynamic DNS updates to a zone, or for the rndc <#std-iscman-rndc> command channel.

The key name can specified using -k parameter and defaults to ddns-key. The generated key is accompanied by configuration text and instructions that can be used with nsupdate <#std-iscman-nsupdate> and named <#std-iscman-named> when setting up dynamic DNS, including an example update-policy statement. (This usage is similar to the rndc-confgen <#std-iscman-rndc-confgen> command for setting up command-channel security.)

Note that named <#std-iscman-named> itself can configure a local DDNS key for use with nsupdate -l <#cmdoption-nsupdate-l>; it does this when a zone is configured with update-policy local;. ddns-confgen is only needed when a more elaborate configuration is required: for instance, if nsupdate <#std-iscman-nsupdate> is to be used from a remote system.

## OPTIONS
-a algorithm

This option specifies the algorithm to use for the TSIG key. Available choices are: hmac-md5, hmac-sha1, hmac-sha224, hmac-sha256, hmac-sha384, and hmac-sha512. The default is hmac-sha256. Options are case-insensitive, and the "hmac-" prefix may be omitted.

-h

This option prints a short summary of options and arguments.

-k keyname

This option specifies the key name of the DDNS authentication key. The default is ddns-key when neither the -s nor -z option is specified; otherwise, the default is ddns-key as a separate label followed by the argument of the option, e.g., ddns-key.example.com. The key name must have the format of a valid domain name, consisting of letters, digits, hyphens, and periods.

-q

This option enables quiet mode, which prints only the key, with no explanatory text or usage examples. This is essentially identical to tsig-keygen <#std-iscman-tsig-keygen>.

-s name

This option generates a configuration example to allow dynamic updates of a single hostname. The example named.conf <#std-iscman-named.conf> text shows how to set an update policy for the specified name using the "name" nametype. The default key name is ddns-key.name. Note that the "self" nametype cannot be used, since the name to be updated may differ from the key name. This option cannot be used with the -z option.

-z zone

This option generates a configuration example to allow dynamic updates of a zone. The example named.conf <#std-iscman-named.conf> text shows how to set an update policy for the specified zone using the "zonesub" nametype, allowing updates to all subdomain names within that zone. This option cannot be used with the -s option.

## SEE ALSO
nsupdate(1) <#std-iscman-nsupdate>, named.conf(5) <#std-iscman-named.conf>, named(8) <#std-iscman-named>, BIND 9 Administrator Reference Manual.

## Author
Internet Systems Consortium

## Copyright
2026, Internet Systems Consortium


filter-a

title: filter-a(8)

text:
# filter-a(8)

## NAME
filter-a - filter A in DNS responses when AAAA is present

## SYNOPSIS
plugin query "filter-a.so" [{ parameters }];

## DESCRIPTION
filter-a.so is a query plugin module for named <#std-iscman-named>, enabling named <#std-iscman-named> to omit some IPv4 addresses when responding to clients.

For example:

```
plugin query "filter-a.so" {

        filter-a-on-v6 yes;

        filter-a-on-v4 yes;

        filter-a { 192.0.2.1; 2001:db8:2::1; };
};
```

This module is intended to aid transition from IPv4 to IPv6 by withholding IPv4 addresses from DNS clients which are not connected to the IPv4 Internet, when the name being looked up has an IPv6 address available. Use of this module is not recommended unless absolutely necessary.

Note: This mechanism can erroneously cause other servers not to give A records to their clients. If a recursing server with both IPv6 and IPv4 network connections queries an authoritative server using this mechanism via IPv6, it is denied A records even if its client is using IPv4.

## OPTIONS
filter-a

This option specifies a list of client addresses for which A filtering is to be applied. The default is any.

filter-a-on-v6

If set to yes, this option indicates that the DNS client is at an IPv6 address, in filter-a. If the response does not include DNSSEC signatures, then all A records are deleted from the response. This filtering applies to all responses, not only authoritative ones. If set to break-dnssec, then A records are deleted even when DNSSEC is enabled. As suggested by the name, this causes the response to fail to verify, because the DNSSEC protocol is designed to detect deletions.

This mechanism can erroneously cause other servers not to give A records to their clients. If a recursing server with both IPv6 and IPv4 network connections queries an authoritative server using this mechanism via IPv6, it is denied A records even if its client is using IPv4.

filter-a-on-v4

This option is identical to filter-a-on-v6, except that it filters A responses to queries from IPv4 clients instead of IPv6 clients. To filter all responses, set both options to yes.

## SEE ALSO
BIND 9 Administrator Reference Manual.

## Author
Internet Systems Consortium

## Copyright
2026, Internet Systems Consortium


filter-aaaa

title: filter-aaaa(8)

text:
# filter-aaaa(8)

## NAME
filter-aaaa - filter AAAA in DNS responses when A is present

## SYNOPSIS
plugin query "filter-aaaa.so" [{ parameters }];

## DESCRIPTION
filter-aaaa.so is a query plugin module for named <#std-iscman-named>, enabling named <#std-iscman-named> to omit some IPv6 addresses when responding to clients.

Until BIND 9.12, this feature was implemented natively in named <#std-iscman-named> and enabled with the filter-aaaa ACL and the filter-aaaa-on-v4 and filter-aaaa-on-v6 options. These options are now deprecated in named.conf <#std-iscman-named.conf> but can be passed as parameters to the filter-aaaa.so plugin, for example:

```
plugin query "filter-aaaa.so" {

        filter-aaaa-on-v4 yes;

        filter-aaaa-on-v6 yes;

        filter-aaaa { 192.0.2.1; 2001:db8:2::1; };
};
```

This module is intended to aid transition from IPv4 to IPv6 by withholding IPv6 addresses from DNS clients which are not connected to the IPv6 Internet, when the name being looked up has an IPv4 address available. Use of this module is not recommended unless absolutely necessary.

Note: This mechanism can erroneously cause other servers not to give AAAA records to their clients. If a recursing server with both IPv6 and IPv4 network connections queries an authoritative server using this mechanism via IPv4, it is denied AAAA records even if its client is using IPv6.

## OPTIONS
filter-aaaa

This option specifies a list of client addresses for which AAAA filtering is to be applied. The default is any.

filter-aaaa-on-v4

If set to yes, this option indicates that the DNS client is at an IPv4 address, in filter-aaaa. If the response does not include DNSSEC signatures, then all AAAA records are deleted from the response. This filtering applies to all responses, not only authoritative ones. If set to break-dnssec, then AAAA records are deleted even when DNSSEC is enabled. As suggested by the name, this causes the response to fail to verify, because the DNSSEC protocol is designed to detect deletions.

This mechanism can erroneously cause other servers not to give AAAA records to their clients. If a recursing server with both IPv6 and IPv4 network connections queries an authoritative server using this mechanism via IPv4, it is denied AAAA records even if its client is using IPv6.

filter-aaaa-on-v6

This option is identical to filter-aaaa-on-v4, except that it filters AAAA responses to queries from IPv6 clients instead of IPv4 clients. To filter all responses, set both options to yes.

## SEE ALSO
BIND 9 Administrator Reference Manual.

## Author
Internet Systems Consortium

## Copyright
2026, Internet Systems Consortium


named

title: named(8)

summary: Internet domain name server

text:
# named(8)

## NAME
named - Internet domain name server

## SYNOPSIS
named [ [-4] | [-6] ] [-c config-file] [-C] [-d debug-level] [-D string] [-E engine-name] [-f] [-g] [-L logfile] [-M option] [-m flag] [-n #cpus] [-p port] [-s] [-t directory] [-U #listeners] [-u user] [-v] [-V] [-X lock-file]

## DESCRIPTION
named is a Domain Name System (DNS) server, part of the BIND 9 distribution from ISC. For more information on the DNS, see RFC 1033 <https://datatracker.ietf.org/doc/html/rfc1033.html>, RFC 1034 <https://datatracker.ietf.org/doc/html/rfc1034.html>, and RFC 1035 <https://datatracker.ietf.org/doc/html/rfc1035.html>.

When invoked without arguments, named reads the default configuration file /etc/named.conf, reads any initial data, and listens for queries.

## OPTIONS
-4

This option tells named to use only IPv4, even if the host machine is capable of IPv6. -4 and -6 are mutually exclusive.

-6

This option tells named to use only IPv6, even if the host machine is capable of IPv4. -4 and -6 are mutually exclusive.

-c config-file

This option tells named to use config-file as its configuration file instead of the default, /etc/named.conf. To ensure that the configuration file can be reloaded after the server has changed its working directory due to to a possible directory option in the configuration file, config-file should be an absolute pathname.

-C

This option prints out the default built-in configuration and exits. NOTE: This is for debugging purposes only and is not an accurate representation of the actual configuration used by named at runtime.

-d debug-level

This option sets the daemon's debug level to debug-level. Debugging traces from named become more verbose as the debug level increases.

-D string

This option specifies a string that is used to identify a instance of named in a process listing. The contents of string are not examined.

-E engine-name

When applicable, this option specifies the hardware to use for cryptographic operations, such as a secure key store used for signing. When BIND 9 is built with OpenSSL, this needs to be set to the OpenSSL engine identifier that drives the cryptographic accelerator or hardware service module (usually pkcs11).

-f

This option runs the server in the foreground (i.e., do not daemonize).

-g

This option runs the server in the foreground and forces all logging to stderr.

-L logfile

This option sets the log to the file logfile by default, instead of the system log.

-M option

This option sets the default (comma-separated) memory context options. The possible flags are:

- fill: fill blocks of memory with tag values when they are allocated or freed, to assist debugging of memory problems; this is the implicit default if named has been compiled with --enable-developer.

- nofill: disable the behavior enabled by fill; this is the implicit default unless named has been compiled with --enable-developer.

-m flag

This option turns on memory usage debugging flags. Possible flags are usage, trace and record. These correspond to the ISC_MEM_DEBUGXXXX flags described in <isc/mem.h>.

-n #cpus

This option creates #cpus worker threads to take advantage of multiple CPUs. If not specified, named tries to determine the number of CPUs present and creates one thread per CPU. If it is unable to determine the number of CPUs, a single worker thread is created.

-p value

This option specifies the port(s) on which the server will listen for queries. If value is of the form <portnum> or dns=<portnum>, the server will listen for DNS queries on portnum; if not not specified, the default is port 53. If value is of the form tls=<portnum>, the server will listen for TLS queries on portnum; the default is 853. If value is of the form https=<portnum>, the server will listen for HTTPS queries on portnum; the default is 443. If value is of the form http=<portnum>, the server will listen for HTTP queries on portnum; the default is 80.

-s

This option writes memory usage statistics to stdout on exit.

Note:

This option is mainly of interest to BIND 9 developers and may be removed or changed in a future release.

-S #max-socks

This option is deprecated and no longer has any function.

Warning:

This option should be unnecessary for the vast majority of users. The use of this option could even be harmful, because the specified value may exceed the limitation of the underlying system API. It is therefore set only when the default configuration causes exhaustion of file descriptors and the operational environment is known to support the specified number of sockets. Note also that the actual maximum number is normally slightly fewer than the specified value, because named reserves some file descriptors for its internal use.

-t directory

This option tells named to chroot to directory after processing the command-line arguments, but before reading the configuration file.

Warning:

This option should be used in conjunction with the -u option, as chrooting a process running as root doesn't enhance security on most systems; the way chroot is defined allows a process with root privileges to escape a chroot jail.

-U #dispatches

This option specifies the number of per-interface UDP #dispatches that named should use to handle the outgoing (recursive) UDP connection, to reduce contention between the resolver threads. If not specified, named calculates a default value based on the number of detected CPUs: 1 for a single CPU, and the number of detected CPUs minus one for machines with more than 1 CPU.

This cannot be increased to a value higher than the number of CPUs (see -n on how to override the value).

Warning:

This option should be unnecessary for the vast majority of users, and will be removed in the next version of BIND 9.

-u user

This option sets the setuid to user after completing privileged operations, such as creating sockets that listen on privileged ports.

Note:

On Linux, named uses the kernel's capability mechanism to drop all root privileges except the ability to bind to a privileged port and set process resource limits. Unfortunately, this means that the -u option only works when named is run on kernel 2.2.18 or later, or kernel 2.3.99-pre3 or later, since previous kernels did not allow privileges to be retained after setuid.

-v

This option reports the version number and exits.

-V

This option reports the version number, build options, supported cryptographics algorithms, and exits.

-X lock-file

This option acquires a lock on the specified file at runtime; this helps to prevent duplicate named instances from running simultaneously. Use of this option overrides the lock-file option in named.conf <#std-iscman-named.conf>. If set to none, the lock file check is disabled.

## SIGNALS
In routine operation, signals should not be used to control the nameserver; rndc <#std-iscman-rndc> should be used instead.

SIGHUP

This signal forces a reload of the server.

SIGINT, SIGTERM

These signals shut down the server.

The result of sending any other signals to the server is undefined.

## CONFIGURATION
The named configuration file is too complex to describe in detail here. A complete description is provided in the BIND 9 Administrator Reference Manual.

named inherits the umask (file creation mode mask) from the parent process. If files created by named, such as journal files, need to have custom permissions, the umask should be set explicitly in the script used to start the named process.

## FILES
/etc/named.conf

The default configuration file.

/var/run/named.pid

The default process-id file.

## SEE ALSO
RFC 1033 <https://datatracker.ietf.org/doc/html/rfc1033.html>, RFC 1034 <https://datatracker.ietf.org/doc/html/rfc1034.html>, RFC 1035 <https://datatracker.ietf.org/doc/html/rfc1035.html>, named-checkconf(8) <#std-iscman-named-checkconf>, named-checkzone(8) <#std-iscman-named-checkzone>, rndc(8) <#std-iscman-rndc>, named.conf(5) <#std-iscman-named.conf>, BIND 9 Administrator Reference Manual.

## Author
Internet Systems Consortium

## Copyright
2026, Internet Systems Consortium


rndc

title: rndc(8)

summary: name server control utility

text:
# rndc(8)

## NAME
rndc - name server control utility

## SYNOPSIS
rndc [-b source-address] [-c config-file] [-k key-file] [-s server] [-p port] [-q] [-r] [-V] [-y server_key] [[-4] | [-6]] {command}

## DESCRIPTION
rndc controls the operation of a name server. If rndc is invoked with no command line options or arguments, it prints a short summary of the supported commands and the available options and their arguments.

rndc communicates with the name server over a TCP connection, sending commands authenticated with digital signatures. In the current versions of rndc and named <#std-iscman-named>, the only supported authentication algorithms are HMAC-MD5 (for compatibility), HMAC-SHA1, HMAC-SHA224, HMAC-SHA256 (default), HMAC-SHA384, and HMAC-SHA512. They use a shared secret on each end of the connection, which provides TSIG-style authentication for the command request and the name server's response. All commands sent over the channel must be signed by a server_key known to the server.

rndc reads a configuration file to determine how to contact the name server and decide what algorithm and key it should use.

## OPTIONS
-4

This option indicates use of IPv4 only.

-6

This option indicates use of IPv6 only.

-b source-address

This option indicates source-address as the source address for the connection to the server. Multiple instances are permitted, to allow setting of both the IPv4 and IPv6 source addresses.

-c config-file

This option indicates config-file as the configuration file instead of the default, /etc/rndc.conf.

-k key-file

This option indicates key-file as the key file instead of the default, /etc/rndc.key. The key in /etc/rndc.key is used to authenticate commands sent to the server if the config-file does not exist.

-s server

server is the name or address of the server which matches a server statement in the configuration file for rndc. If no server is supplied on the command line, the host named by the default-server clause in the options statement of the rndc configuration file is used.

-p port

This option instructs BIND 9 to send commands to TCP port port instead of its default control channel port, 953.

-q

This option sets quiet mode, where message text returned by the server is not printed unless there is an error.

-r

This option instructs rndc to print the result code returned by named <#std-iscman-named> after executing the requested command (e.g., ISC_R_SUCCESS, ISC_R_FAILURE, etc.).

-V

This option enables verbose logging.

-y server_key

This option indicates use of the key server_key from the configuration file. For control message validation to succeed, server_key must be known by named <#std-iscman-named> with the same algorithm and secret string. If no server_key is specified, rndc first looks for a key clause in the server statement of the server being used, or if no server statement is present for that host, then in the default-key clause of the options statement. Note that the configuration file contains shared secrets which are used to send authenticated control commands to name servers, and should therefore not have general read or write access.

## COMMANDS
A list of commands supported by rndc can be seen by running rndc without arguments.

Currently supported commands are:

addzone zone [class [view]] configuration

This command adds a zone while the server is running. This command requires the allow-new-zones option to be set to yes. The configuration string specified on the command line is the zone configuration text that would ordinarily be placed in named.conf <#std-iscman-named.conf>. The configuration is saved in a file called viewname.nzf (or, if named <#std-iscman-named> is compiled with liblmdb, an LMDB database file called viewname.nzd). viewname is the name of the view, unless the view name contains characters that are incompatible with use as a file name, in which case a cryptographic hash of the view name is used instead. When named <#std-iscman-named> is restarted, the file is loaded into the view configuration so that zones that were added can persist after a restart.

This sample addzone command adds the zone example.com to the default view:

rndc addzone example.com '{ type primary; file "example.com.db"; };'

(Note the brackets around and semi-colon after the zone configuration text.)

See also rndc delzone and rndc modzone.

delzone [-clean] zone [class [view]]

This command deletes a zone while the server is running. If the -clean argument is specified, the zone's master file (and journal file, if any) are deleted along with the zone. Without the -clean option, zone files must be deleted manually. (If the zone is of type secondary or stub, the files needing to be removed are reported in the output of the rndc delzone command.)

If the zone was originally added via rndc addzone, then it is removed permanently. However, if it was originally configured in named.conf <#std-iscman-named.conf>, then that original configuration remains in place; when the server is restarted or reconfigured, the zone is recreated. To remove it permanently, it must also be removed from named.conf <#std-iscman-named.conf>.

See also rndc addzone and rndc modzone.

dnssec (-status | -rollover -key id [-alg algorithm] [-when time] | -checkds [-key id [-alg algorithm]] [-when time] published | withdrawn)) zone [class [view]]

This command allows you to interact with the "dnssec-policy" of a given zone. rndc dnssec -status show the DNSSEC signing state for the specified zone.

rndc dnssec -rollover allows you to schedule key rollover for a specific key (overriding the original key lifetime).

rndc dnssec -checkds informs named <#std-iscman-named> that the DS for a specified zone's key-signing key has been confirmed to be published in, or withdrawn from, the parent zone. This is required in order to complete a KSK rollover. The -key id and -alg algorithm arguments can be used to specify a particular KSK, if necessary; if there is only one key acting as a KSK for the zone, these arguments can be omitted. The time of publication or withdrawal for the DS is set to the current time by default, but can be overridden to a specific time with the argument -when time, where time is expressed in YYYYMMDDHHMMSS notation.

dnstap (-reopen | -roll [number])

This command closes and re-opens DNSTAP output files. rndc dnstap -reopen allows the output file to be renamed externally, so that named <#std-iscman-named> can truncate and re-open it.

rndc dnstap -roll causes the output file to be rolled automatically, similar to log files. The most recent output file has ".0" appended to its name; the previous most recent output file is moved to ".1", and so on. If number is specified, then the number of backup log files is limited to that number.

dumpdb [-all | -cache | -zones | -adb | -bad | -expired | -fail] [view ...]

This command dumps the server's caches (default) and/or zones to the dump file for the specified views. If no view is specified, all views are dumped. (See the dump-file option in the BIND 9 Administrator Reference Manual.)

flush

This command flushes the server's cache.

flushname name [view]

This command flushes the given name from the view's DNS cache and, if applicable, from the view's nameserver address database, bad server cache, and SERVFAIL cache.

flushtree name [view]

This command flushes the given name, and all of its subdomains, from the view's DNS cache, address database, bad server cache, and SERVFAIL cache.

freeze [zone [class [view]]]

This command suspends updates to a dynamic zone. If no zone is specified, then all zones are suspended. This allows manual edits to be made to a zone normally updated by dynamic update, and causes changes in the journal file to be synced into the master file. All dynamic update attempts are refused while the zone is frozen. See also rndc thaw.

halt [-p]

This command stops the server immediately. Recent changes made through dynamic update or IXFR are not saved to the master files, but are rolled forward from the journal files when the server is restarted. If -p is specified, named <#std-iscman-named>'s process ID is returned. This allows an external process to determine when named <#std-iscman-named> has completed halting. See also rndc stop.

loadkeys [zone [class [view]]]

This command fetches all DNSSEC keys for the given zone from the key directory. If they are within their publication period, they are merged into the zone's DNSKEY RRset. Unlike rndc sign, however, the zone is not immediately re-signed by the new keys, but is allowed to incrementally re-sign over time. This command requires that the zone be configured with a dnssec-policy, or that the auto-dnssec zone option be set to maintain, and also requires the zone to be configured to allow dynamic DNS. (See "Dynamic Update Policies" in the Administrator Reference Manual for more details.)

managed-keys (status | refresh | sync | destroy) [class [view]]

This command inspects and controls the "managed-keys" database which handles RFC 5011 <https://datatracker.ietf.org/doc/html/rfc5011.html> DNSSEC trust anchor maintenance. If a view is specified, these commands are applied to that view; otherwise, they are applied to all views.

- When run with the status keyword, this prints the current status of the managed-keys database.

- When run with the refresh keyword, this forces an immediate refresh query to be sent for all the managed keys, updating the managed-keys database if any new keys are found, without waiting the normal refresh interval.

- When run with the sync keyword, this forces an immediate dump of the managed-keys database to disk (in the file managed-keys.bind or (viewname.mkeys). This synchronizes the database with its journal file, so that the database's current contents can be inspected visually.

- When run with the destroy keyword, the managed-keys database is shut down and deleted, and all key maintenance is terminated. This command should be used only with extreme caution. Existing keys that are already trusted are not deleted from memory; DNSSEC validation can continue after this command is used. However, key maintenance operations cease until named <#std-iscman-named> is restarted or reconfigured, and all existing key maintenance states are deleted.

Running rndc reconfig or restarting named <#std-iscman-named> immediately after this command causes key maintenance to be reinitialized from scratch, just as if the server were being started for the first time. This is primarily intended for testing, but it may also be used, for example, to jumpstart the acquisition of new keys in the event of a trust anchor rollover, or as a brute-force repair for key maintenance problems.

modzone zone [class [view]] configuration

This command modifies the configuration of a zone while the server is running. This command requires the allow-new-zones option to be set to yes. As with addzone, the configuration string specified on the command line is the zone configuration text that would ordinarily be placed in named.conf <#std-iscman-named.conf>. If the zone was originally added via rndc addzone, the configuration changes are recorded permanently and are still in effect after the server is restarted or reconfigured. However, if it was originally configured in named.conf <#std-iscman-named.conf>, then that original configuration remains in place; when the server is restarted or reconfigured, the zone reverts to its original configuration. To make the changes permanent, it must also be modified in named.conf <#std-iscman-named.conf>.

See also rndc addzone and rndc delzone.

notify zone [class [view]]

This command resends NOTIFY messages for the zone.

notrace

This command sets the server's debugging level to 0. See also rndc trace.

nta [(-class class | -dump | -force | -remove | -lifetime duration)] domain [view]

This command sets a DNSSEC negative trust anchor (NTA) for domain, with a lifetime of duration. The default lifetime is configured in named.conf <#std-iscman-named.conf> via the nta-lifetime option, and defaults to one hour. The lifetime cannot exceed one week. A negative trust anchor selectively disables DNSSEC validation for zones that are known to be failing because of misconfiguration rather than an attack. When data to be validated is at or below an active NTA (and above any other configured trust anchors), named <#std-iscman-named> aborts the DNSSEC validation process and treats the data as insecure rather than bogus. This continues until the NTA's lifetime has elapsed.

NTAs persist across restarts of the named <#std-iscman-named> server. The NTAs for a view are saved in a file called name.nta, where name is the name of the view; if it contains characters that are incompatible with use as a file name, a cryptographic hash is generated from the name of the view.

An existing NTA can be removed by using the -remove option.

An NTA's lifetime can be specified with the -lifetime option. TTL-style suffixes can be used to specify the lifetime in seconds, minutes, or hours. If the specified NTA already exists, its lifetime is updated to the new value. Setting lifetime to zero is equivalent to -remove.

If -dump is used, any other arguments are ignored and a list of existing NTAs is printed. Note that this may include NTAs that are expired but have not yet been cleaned up.

Normally, named <#std-iscman-named> periodically tests to see whether data below an NTA can now be validated (see the nta-recheck option in the Administrator Reference Manual for details). If data can be validated, then the NTA is regarded as no longer necessary and is allowed to expire early. The -force parameter overrides this behavior and forces an NTA to persist for its entire lifetime, regardless of whether data could be validated if the NTA were not present.

The view class can be specified with -class. The default is class IN, which is the only class for which DNSSEC is currently supported.

All of these options can be shortened, i.e., to -l, -r, -d, -f, and -c.

Unrecognized options are treated as errors. To refer to a domain or view name that begins with a hyphen, use a double-hyphen (--) on the command line to indicate the end of options.

querylog [(on | off)]

This command enables or disables query logging. For backward compatibility, this command can also be used without an argument to toggle query logging on and off. Query logging can also be enabled by explicitly directing the queries category to a channel in the logging section of named.conf <#std-iscman-named.conf>, or by specifying querylog yes; in the options section of named.conf <#std-iscman-named.conf>.

reconfig

This command reloads the configuration file and loads new zones, but does not reload existing zone files even if they have changed. This is faster than a full rndc reload when there is a large number of zones, because it avoids the need to examine the modification times of the zone files.

recursing

This command dumps the list of queries named <#std-iscman-named> is currently recursing on, and the list of domains to which iterative queries are currently being sent. The first list includes all unique clients that are waiting for recursion to complete, including the query that is awaiting a response and the timestamp (seconds since the Unix epoch) of when named started processing this client query.

The second list comprises of domains for which there are active (or recently active) fetches in progress. It reports the number of active fetches for each domain and the number of queries that have been passed (allowed) or dropped (spilled) as a result of the fetches-per-zone limit. (Note: these counters are not cumulative over time; whenever the number of active fetches for a domain drops to zero, the counter for that domain is deleted, and the next time a fetch is sent to that domain, it is recreated with the counters set to zero).

refresh zone [class [view]]

This command schedules zone maintenance for the given zone.

reload

This command reloads the configuration file and zones.

zone [class [view]]

If a zone is specified, this command reloads only the given zone. If no zone is specified, the reloading happens asynchronously.

retransfer zone [class [view]]

This command retransfers the given secondary zone from the primary server. If the zone is configured to use inline-signing, the signed version of the zone is discarded; after the retransfer of the unsigned version is complete, the signed version is regenerated with new signatures.

scan

This command scans the list of available network interfaces for changes, without performing a full rndc reconfig or waiting for the interface-interval timer.

secroots [-] [view ...]

This command dumps the security roots (i.e., trust anchors configured via trust-anchors, or the managed-keys or trusted-keys statements [both deprecated], or dnssec-validation auto) and negative trust anchors for the specified views. If no view is specified, all views are dumped. Security roots indicate whether they are configured as trusted keys, managed keys, or initializing managed keys (managed keys that have not yet been updated by a successful key refresh query). If the first argument is -, then the output is returned via the rndc response channel and printed to the standard output. Otherwise, it is written to the secroots dump file, which defaults to named.secroots, but can be overridden via the secroots-file option in named.conf <#std-iscman-named.conf>.

See also rndc managed-keys.

serve-stale (on | off | reset | status) [class [view]]

This command enables, disables, resets, or reports the current status of the serving of stale answers as configured in named.conf <#std-iscman-named.conf>. If serving of stale answers is disabled by rndc-serve-stale off, then it remains disabled even if named <#std-iscman-named> is reloaded or reconfigured. rndc serve-stale reset restores the setting as configured in named.conf <#std-iscman-named.conf>.

rndc serve-stale status reports whether caching and serving of stale answers is currently enabled or disabled. It also reports the values of stale-answer-ttl and max-stale-ttl.

showzone zone [class [view]]

If the server is configured with allow-new-zones set to yes, then this command prints the configuration of a running zone. See also rndc addzone, rndc modzone. and rndc delzone.

sign zone [class [view]]

This command fetches all DNSSEC keys for the given zone from the key directory (see the key-directory option in the BIND 9 Administrator Reference Manual). If they are within their publication period, they are merged into the zone's DNSKEY RRset. If the DNSKEY RRset is changed, then the zone is automatically re-signed with the new key set. This command requires that the zone be configured with a dnssec-policy, or that the auto-dnssec zone option be set to allow or maintain, and also requires the zone to be configured to allow dynamic DNS. (See "Dynamic Update Policies" in the BIND 9 Administrator Reference Manual for more details.)

See also rndc loadkeys.

signing [(-list | -clear keyid/algorithm | -clear all | -nsec3param (parameters | none) | -serial value) zone [class [view]]

This command lists, edits, or removes the DNSSEC signing-state records for the specified zone. The status of ongoing DNSSEC operations, such as signing or generating NSEC3 chains, is stored in the zone in the form of DNS resource records of type sig-signing-type. rndc signing -list converts these records into a human-readable form, indicating which keys are currently signing or have finished signing the zone, and which NSEC3 chains are being created or removed. rndc signing -clear can remove a single key (specified in the same format that rndc signing -list uses to display it), or all keys. In either case, only completed keys are removed; any record indicating that a key has not yet finished signing the zone is retained.

rndc signing -nsec3param sets the NSEC3 parameters for a zone. This is the only supported mechanism for using NSEC3 with inline-signing zones. Parameters are specified in the same format as an NSEC3PARAM resource record: hash algorithm, flags, iterations, and salt, in that order.

Currently, the only defined value for hash algorithm is 1, representing SHA-1. The flags may be set to 0 or 1, depending on whether the opt-out bit in the NSEC3 chain should be set. iterations defines the number of additional times to apply the algorithm when generating an NSEC3 hash. The salt is a string of data expressed in hexadecimal, a hyphen (-) if no salt is to be used, or the keyword auto, which causes named <#std-iscman-named> to generate a random 64-bit salt.

The only recommended configuration is rndc signing -nsec3param 1 0 0 - zone, i.e. no salt, no additional iterations, no opt-out.

Warning:

Do not use extra iterations, salt, or opt-out unless all their implications are fully understood. A higher number of iterations causes interoperability problems and opens servers to CPU-exhausting DoS attacks.

rndc signing -nsec3param none removes an existing NSEC3 chain and replaces it with NSEC.

rndc signing -serial value sets the serial number of the zone to value. If the value would cause the serial number to go backwards, it is rejected. The primary use of this parameter is to set the serial number on inline signed zones.

stats

This command writes server statistics to the statistics file. (See the statistics-file option in the BIND 9 Administrator Reference Manual.)

status

This command displays the status of the server. Note that the number of zones includes the internal bind/CH zone and the default ./IN hint zone, if there is no explicit root zone configured.

stop -p

This command stops the server, making sure any recent changes made through dynamic update or IXFR are first saved to the master files of the updated zones. If -p is specified, named <#std-iscman-named>'s process ID is returned. This allows an external process to determine when named <#std-iscman-named> has completed stopping. See also rndc halt.

sync -clean [zone [class [view]]]

This command syncs changes in the journal file for a dynamic zone to the master file. If the "-clean" option is specified, the journal file is also removed. If no zone is specified, then all zones are synced.

tcp-timeouts [initial idle keepalive advertised]

When called without arguments, this command displays the current values of the tcp-initial-timeout, tcp-idle-timeout, tcp-keepalive-timeout, and tcp-advertised-timeout options. When called with arguments, these values are updated. This allows an administrator to make rapid adjustments when under a denial-of-service (DoS) attack. See the descriptions of these options in the BIND 9 Administrator Reference Manual for details of their use.

thaw [zone [class [view]]]

This command enables updates to a frozen dynamic zone. If no zone is specified, then all frozen zones are enabled. This causes the server to reload the zone from disk, and re-enables dynamic updates after the load has completed. After a zone is thawed, dynamic updates are no longer refused. If the zone has changed and the ixfr-from-differences option is in use, the journal file is updated to reflect changes in the zone. Otherwise, if the zone has changed, any existing journal file is removed. If no zone is specified, the reloading happens asynchronously. See also rndc freeze.

trace [level]

If no level is specified, this command increments the server's debugging level by one.

level

If specified, this command sets the server's debugging level to the provided value.

See also rndc notrace.

tsig-delete keyname [view]

This command deletes a given TKEY-negotiated key from the server. This does not apply to statically configured TSIG keys.

tsig-list

This command lists the names of all TSIG keys currently configured for use by named <#std-iscman-named> in each view. The list includes both statically configured keys and dynamic TKEY-negotiated keys.

validation (on | off | status) [view ...]

This command enables, disables, or checks the current status of DNSSEC validation. By default, validation is enabled. The cache is flushed when validation is turned on or off to avoid using data that might differ between states.

zonestatus zone [class [view]]

This command displays the current status of the given zone, including the master file name and any include files from which it was loaded, when it was most recently loaded, the current serial number, the number of nodes, whether the zone supports dynamic updates, whether the zone is DNSSEC signed, whether it uses automatic DNSSEC key management or inline signing, and the scheduled refresh or expiry times for the zone. See also rndc showzone.

rndc commands that specify zone names, such as reload retransfer, or zonestatus, can be ambiguous when applied to zones of type redirect. Redirect zones are always called ., and can be confused with zones of type hint or with secondary copies of the root zone. To specify a redirect zone, use the special zone name -redirect, without a trailing period. (With a trailing period, this would specify a zone called "-redirect".)

## LIMITATIONS
There is currently no way to provide the shared secret for a server_key without using the configuration file.

Several error messages could be clearer.

## SEE ALSO
rndc.conf(5) <#std-iscman-rndc.conf>, rndc-confgen(8) <#std-iscman-rndc-confgen>, named(8) <#std-iscman-named>, named.conf(5) <#std-iscman-named.conf>, BIND 9 Administrator Reference Manual.

## Author
Internet Systems Consortium

## Copyright
2026, Internet Systems Consortium


rndc-confgen

title: rndc-confgen(8)

summary: rndc key generation tool

text:
# rndc-confgen(8)

## NAME
rndc-confgen - rndc key generation tool

## SYNOPSIS
rndc-confgen [-a] [-A algorithm] [-b keysize] [-c keyfile] [-h] [-k keyname] [-p port] [-s address] [-t chrootdir] [-u user]

## DESCRIPTION
rndc-confgen generates configuration files for rndc <#std-iscman-rndc>. It can be used as a convenient alternative to writing the rndc.conf <#std-iscman-rndc.conf> file and the corresponding controls and key statements in named.conf <#std-iscman-named.conf> by hand. Alternatively, it can be run with the -a option to set up a rndc.key file and avoid the need for a rndc.conf <#std-iscman-rndc.conf> file and a controls statement altogether.

## OPTIONS
-a

This option sets automatic rndc <#std-iscman-rndc> configuration, which creates a file /etc/rndc.key that is read by both rndc <#std-iscman-rndc> and named <#std-iscman-named> on startup. The rndc.key file defines a default command channel and authentication key allowing rndc <#std-iscman-rndc> to communicate with named <#std-iscman-named> on the local host with no further configuration. If a more elaborate configuration than that generated by rndc-confgen -a is required, for example if rndc is to be used remotely, run rndc-confgen without the -a option and set up rndc.conf <#std-iscman-rndc.conf> and named.conf <#std-iscman-named.conf> as directed.

-A algorithm

This option specifies the algorithm to use for the TSIG key. Available choices are: hmac-md5, hmac-sha1, hmac-sha224, hmac-sha256, hmac-sha384, and hmac-sha512. The default is hmac-sha256.

-b keysize

This option specifies the size of the authentication key in bits. The size must be between 1 and 512 bits; the default is the hash size.

-c keyfile

This option is used with the -a option to specify an alternate location for rndc.key.

-h

This option prints a short summary of the options and arguments to rndc-confgen.

-k keyname

This option specifies the key name of the rndc <#std-iscman-rndc> authentication key. This must be a valid domain name. The default is rndc-key.

-p port

This option specifies the command channel port where named <#std-iscman-named> listens for connections from rndc <#std-iscman-rndc>. The default is 953.

-q

This option prevets printing the written path in automatic configuration mode.

-s address

This option specifies the IP address where named <#std-iscman-named> listens for command-channel connections from rndc <#std-iscman-rndc>. The default is the loopback address 127.0.0.1.

-t chrootdir

This option is used with the -a option to specify a directory where named <#std-iscman-named> runs chrooted. An additional copy of the rndc.key is written relative to this directory, so that it is found by the chrooted named <#std-iscman-named>.

-u user

This option is used with the -a option to set the owner of the generated rndc.key file. If -t is also specified, only the file in the chroot area has its owner changed.

## EXAMPLES
To allow rndc <#std-iscman-rndc> to be used with no manual configuration, run:

rndc-confgen -a

To print a sample rndc.conf <#std-iscman-rndc.conf> file and the corresponding controls and key statements to be manually inserted into named.conf <#std-iscman-named.conf>, run:

rndc-confgen

## SEE ALSO
rndc(8) <#std-iscman-rndc>, rndc.conf(5) <#std-iscman-rndc.conf>, named(8) <#std-iscman-named>, BIND 9 Administrator Reference Manual.

## Author
Internet Systems Consortium

## Copyright
2026, Internet Systems Consortium


tsig-keygen

title: tsig-keygen(8)

summary: TSIG key generation tool

text:
# tsig-keygen(8)

## NAME
tsig-keygen - TSIG key generation tool

## SYNOPSIS
tsig-keygen [-a algorithm] [-h] [name]

## DESCRIPTION
tsig-keygen is an utility that generates keys for use with TSIG (Transaction Signatures) as defined in RFC 2845 <https://datatracker.ietf.org/doc/html/rfc2845.html>. The resulting keys can be used, for example, to secure dynamic DNS updates to a zone, or for the rndc <#std-iscman-rndc> command channel.

A domain name can be specified on the command line to be used as the name of the generated key. If no name is specified, the default is tsig-key.

## OPTIONS
-a algorithm

This option specifies the algorithm to use for the TSIG key. Available choices are: hmac-md5, hmac-sha1, hmac-sha224, hmac-sha256, hmac-sha384, and hmac-sha512. The default is hmac-sha256. Options are case-insensitive, and the "hmac-" prefix may be omitted.

-h

This option prints a short summary of options and arguments.

## SEE ALSO
nsupdate(1) <#std-iscman-nsupdate>, named.conf(5) <#std-iscman-named.conf>, named(8) <#std-iscman-named>, BIND 9 Administrator Reference Manual.

## Author
Internet Systems Consortium

## Copyright
2026, Internet Systems Consortium


bing

package: bing

title: bing(8)

text:
# bing(8)

## NAME
bing — compute point to point throughput using two sizes of ICMP ECHO_REQUEST packets to pairs of remote hosts.

## SYNOPSIS
bing

[-dDnrRPvVwz] [-c count] [-e samples] [-f samplefile] [-i wait] [-p pattern] [-s small packetsize] [-S big packetsize] [-u size increment] host1 host2 [...]

## DESCRIPTION
Bing determines bandwidth on a point-to-point link by sending ICMP ECHO_REQUEST packets and measuring their roundtrip times for different packet sizes on each end of the link.

host1 is supposed to be the nearest end of the link, while host2 is the other end.

The options are as follows:

-c count

Stop after count resets of the stats. Useful only in conjunction with the -e option. Defaults to 1.

-d

Set the SO_DEBUG option on the socket being used.

-D

Display the measured throughput at every received packet. By default, it is displayed only when the computed value changes, which itself changes only when the minimum roundtrip time for one of the packet sizes changes.

-e samples

Reset stats after sending samples ECHO_REQUEST packets.

-f samplefile

Saves the bandwidth measurements to the file samplefile.

-i wait

Wait wait seconds for each ECHO_REPLY packet. The default is to wait for four seconds.

-n

Numeric output only. No attempt will be made to lookup symbolic names for host addresses.

-P

Be pedantic regarding round-trip times. Normally, bing assumes that the roundtrip time for a small packet should always be smaller than the roundtrip time for a big packet to the same host, that for a given size the roundtrip time for host1 should always be smaller than the roundtrip time for host2, and that the increase in the roundtrip time between host1 and host2 should always be bigger for big packets than for small packets.

Bing takes advantage of this to better determine the minimum roundtrip times.

Option -P disables this behaviour, in the unlikely event it could be of any use someday. Even IP/X25 links are not weird enough to require this, though.

-p pattern

You may specify up to 16 ``pad'' bytes to fill out the packet you send. This is useful for diagnosing data-dependent problems in a network. For example, “-p ff” will cause the sent packet to be filled with all ones.

-R

Record route. Includes the RECORD_ROUTE option in the ECHO_REQUEST packet and displays the route buffer on returned packets. Note that the IP header is only large enough for nine such routes. Many hosts ignore or discard this option.

-r

Bypass the normal routing tables and send directly to a host on an attached network. If the host is not on a directly-attached network, an error is returned. This option can be used to ping a local host through an interface that has no route through it (e.g., after the interface was dropped by routed(8) ).

-s packetsize

Specifies the number of data bytes to be sent in the small packets. The default and minimum value is 8.

-S packetsize

Specifies the number of data bytes to be sent in the big packets. The default is 108. The size should be chosen so that big packet roundtrip times are long enough to be accurately measured (depending on clock resolution and number of hops).

-u size increment

Specifies that bing should start sending packets of the size of small packetsize and then increase the size by size increment until it reaches big packetsize.

-v

Verbose output. ICMP packets other than ECHO_RESPONSE that are received are listed.

-V

Very verbose output. The roundtrip time of each received echo is displayed.

-w

Display possible warnings about roundtrip times all the time. By default, warnings are printed only at the end.

-z

Fill packets with uncompressible (pseudo-random) data.

Round-trip times and packet loss statistics are computed. If duplicate packets are received, they are not included in the packet loss calculation, although the round trip time of these packets is used in calculating the minimum/average/maximum round-trip time numbers. When the specified number of loops have been made or if the program is terminated with a SIGINT, a brief summary is displayed.

This program is intended for use in network testing, measurement and management. Because of the load it can impose on the network, it is unwise to use bing during normal operations or from automated scripts.

## BUGS
Many Hosts and Gateways ignore the RECORD_ROUTE option.

The maximum IP header length is too small for options like RECORD_ROUTE to be completely useful. There's not much that that can be done about this, however.

Some of the final stats (average throughputs) almost never give a even marginally correct result.

## SEE ALSO
netstat(1), ifconfig(8), ping(8), routed(8), traceroute(8)

## AUTHOR
Pierre Beyssac <pb@fasterix.freenix.fr>


binkd

package: binkd

title: binkd(8)

text:
# binkd(8)

## NAME
binkd - transfer files between two Fidonet systems over TCP/IP

## SYNOPSIS
binkd [-CcDipqrsvdmh] [ -P node ] config-file

## DESCRIPTION
Binkd is a Fidonet mailer designed to operate via TCP/IP networks. As a FTN-compatible internet daemon, it makes possible efficient utilization of TCP/IP protocol suite as a transport layer in FTN-based (Fido Technology Network) networks.

Binkd expects your spool for Fido-like networks to be in BSO ("Bink style outbound") or optionaly ASO ("Amiga style outbound") format. BSO is also used by ifmail and BinkleyTerm mailers.

## OPTIONS
-C

Binkd running with this option will reread the configuration file if it is changed. The modification time of the configuration file is checked every 60 seconds and on every incoming and outgoing connection.

-c

Start client only. Normally Binkd starts both server and client.

-D

Run Binkd as a daemon (cannot be used for client-only mode).

-i

Run Binkd from inetd.

-P

Poll a node. An empty *.ilo file in the outbound will be created, which will force Binkd to connect to and to receive mail from the node ( Binkd will also add "Node node * -" record to the table-of-nodes in Binkd ´s memory if there is no entry for the node in the configuration file).

-p

Start client manager, process polls, quit if the queue seems to be empty after the next rescan. Implies -c.

-q

Quiet mode. Turns off printq, conlog and percents statements of configuration.

-r

Disable crypt traffic.

-s

Start server only. Normally Binkd starts both server and client.

-v

Be verbose. Binkd -v will dump binkd's version and quit.

-vv

Dump version and compiled-in options.

-d

Dump parsed config and exit.

-m

Disable CRAM-MD5 authorization. Implies -r.

-h

Print help message.

## SIGNALS
SIGHUP

Causes Binkd to reload it's config.

## ENVIROMENT
BINKD_LOG

log file name. Binkd uses this enviroment variable if the logfile token is not defined in the config file

## SEE ALSO
inetd(8)

Binkd FAQ, Binkd User Guide, Binkd homepage http://binkd.grumbler.org, http://www.corbina.net/~maloff/binkd/ ftp://happy.kiev.ua/pub/fidosoft/mailer/binkd/

## AUTHORS
Dima Maloff <maloff@tts.magadan.su> and others.

This manual page is based on "Binkd User Guide" by nsoveiko@doe.carleton.ca (Nick Soveiko)

## REPORTING BUGS
Report bugs to <binkd-bugs@happy.kiev.ua>


bitlbee

package: bitlbee

title: bitlbee(8)

summary: IRC gateway to IM chat networks

text:
# bitlbee(8)

## NAME
BitlBee - IRC gateway to IM chat networks

## SYNOPSIS
bitlbee [-I] [-c configuration file] [-d configuration directory]

bitlbee -D [-i address] [-p port number] [-n] [-v] [-c configuration file] [-d configuration directory]

bitlbee -h

## DESCRIPTION
BitlBee is an IRC daemon that can talk to instant messaging networks and acts as a gateway. Users can connect to the server with any normal IRC client and see their 'buddy list' in &bitlbee.

bitlbee is normally started as a system service (with init scripts, systemd units or equivalent). It can also be run as an inetd(8) / xinetd(8) service or a stand-alone daemon with the options below.

To use it, connect to it with an IRC client with a command such as "/connect localhost"

## RUN MODES
-I

Run in inetd(8) mode. This is the default setting for historical reasons, but not the recommended one (See ForkDaemon below).

-D

Run in Daemon mode. In this mode, BitlBee forks to the background and waits for new connections. All clients will be served from one process. This mode is also useful for debugging.

-F

Run in ForkDaemon mode. This is similar to ordinary daemon mode, but every client gets its own process. Easier to set up than inetd mode, and without the possible stability issues. This is the recommended runmode for most use cases.

## OPTIONS
-i address

When running in daemon mode, specifies the network interface (identified by IP address) to which the daemon should attach. Use this if you don't want BitlBee to listen on every interface (which is the default behaviour).

-p port number

When running in daemon mode, specifies the port number on which BitlBee should listen for connections. 6667 is the default value.

-n

Wehn running in daemon mode, this option prevents BitlBee from forking into the background.

-v

Be more verbose. This only works together with the -n flag.

-c path to other configuration file

Use a different configuration file.

-d path to user settings directory

BitlBee normally saves every user's settings in /var/lib/bitlbee/. If you want the settings to be stored somewhere else (for example, if you don't have write permissions in the default location), use this option.

-h

Show help information.

## COMMANDS
To get a complete list of commands, please use the help commands command in the &bitlbee channel after connecting to bitlbee.

## SEE ALSO
inetd(8), inetd.conf(5)

http://www.bitlbee.org/

For more information on using BitlBee, once connected, you should use the help command in the &bitlbee channel.

## BUGS
Of course there are bugs. If you find some, please report them at http://bugs.bitlbee.org/.

## LICENSE
This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple PLace, Suite 330, Boston, MA 02111-1307 USA

## AUTHORS

Wilmer van der Gaast <wilmer@gaast.net>