protocols

package: man-pages

title: protocols(5)

summary: protocols definition file

text:
# protocols(5)

## NAME
protocols - protocols definition file

## DESCRIPTION
This file is a plain ASCII file, describing the various DARPA internet protocols that are available from the TCP/IP subsystem. It should be consulted instead of using the numbers in the ARPA include files, or, even worse, just guessing them. These numbers will occur in the protocol field of any IP header.

Keep this file untouched since changes would result in incorrect IP packages. Protocol numbers and names are specified by the IANA (Internet Assigned Numbers Authority).

Each line is of the following format:

protocol number aliases ...

where the fields are delimited by spaces or tabs. Empty lines are ignored. If a line contains a hash mark (#), the hash mark and the part of the line following it are ignored.

The field descriptions are:

protocol

the native name for the protocol. For example ip, tcp, or udp.

number

the official number for this protocol as it will appear within the IP header.

aliases

optional aliases for the protocol.

This file might be distributed over a network using a network-wide naming service like Yellow Pages/NIS or BIND/Hesiod.

## FILES
/etc/protocols

The protocols definition file.

## SEE ALSO
getprotoent(3)

http://www.iana.org/assignments/protocol-numbers

branch: sisyphus


repertoiremap

title: repertoiremap(5)

text:
# repertoiremap(5)

## NAME
repertoiremap - map symbolic character names to Unicode code points

## DESCRIPTION
A repertoire map defines mappings between symbolic character names (mnemonics) and Unicode code points when compiling a locale with localedef(1). Using a repertoire map is optional, it is needed only when symbolic names are used instead of now preferred Unicode code points.

### Syntax
The repertoiremap file starts with a header that may consist of the following keywords:

comment_char

is followed by a character that will be used as the comment character for the rest of the file. It defaults to the number sign (#).

escape_char

is followed by a character that should be used as the escape character for the rest of the file to mark characters that should be interpreted in a special way. It defaults to the backslash (\).

The mapping section starts with the keyword CHARIDS in the first column.

The mapping lines have the following form:

<symbolic-name> <code-point> comment

This defines exactly one mapping, comment being optional.

The mapping section ends with the string END CHARIDS.

## FILES
/usr/share/i18n/repertoiremaps

Usual default repertoire map path.

## STANDARDS
POSIX.2.

## NOTES
Repertoire maps are deprecated in favor of Unicode code points.

## EXAMPLES
A mnemonic for the Euro sign can be defined as follows:

```
<Eu> <U20AC> EURO SIGN
```

## SEE ALSO
locale(1), localedef(1), charmap(5), locale(5)


resolv.conf

title: resolv.conf(5)

summary: resolver configuration file

text:
# resolv.conf(5)

## NAME
resolv.conf - resolver configuration file

## SYNOPSIS

```
/etc/resolv.conf
```

## DESCRIPTION
The resolver is a set of routines in the C library that provide access to the Internet Domain Name System (DNS). The resolver configuration file contains information that is read by the resolver routines the first time they are invoked by a process. The file is designed to be human readable and contains a list of keywords with values that provide various types of resolver information. The configuration file is considered a trusted source of DNS information; see the trust-ad option below for details.

If this file does not exist, only the name server on the local machine will be queried, and the search list contains the local domain name determined from the hostname.

The different configuration options are:

nameserver Name server IP address

Internet address of a name server that the resolver should query, either an IPv4 address (in dot notation), or an IPv6 address in colon (and possibly dot) notation as per RFC 2373. Up to MAXNS (currently 3, see <resolv.h>) name servers may be listed, one per keyword. If there are multiple servers, the resolver library queries them in the order listed. If no nameserver entries are present, the default is to use the name server on the local machine. (The algorithm used is to try a name server, and if the query times out, try the next, until out of name servers, then repeat trying all the name servers until a maximum number of retries are made.)

search Search list for host-name lookup.

By default, the search list contains one entry, the local domain name. It is determined from the local hostname returned by gethostname(2); the local domain name is taken to be everything after the first '.'. Finally, if the hostname does not contain a '.', the root domain is assumed as the local domain name.

This may be changed by listing the desired domain search path following the search keyword with spaces or tabs separating the names. Resolver queries having fewer than ndots dots (default is 1) in them will be attempted using each component of the search path in turn until a match is found. For environments with multiple subdomains please read options ndots:n below to avoid man-in-the-middle attacks and unnecessary traffic for the root-dns-servers. Note that this process may be slow and will generate a lot of network traffic if the servers for the listed domains are not local, and that queries will time out if no server is available for one of the domains.

If there are multiple search directives, only the search list from the last instance is used.

In glibc 2.25 and earlier, the search list is limited to six domains with a total of 256 characters. Since glibc 2.26, the search list is unlimited.

The domain directive is an obsolete name for the search directive that handles one search list entry only.

sortlist

This option allows addresses returned by gethostbyname(3) to be sorted. A sortlist is specified by IP-address-netmask pairs. The netmask is optional and defaults to the natural netmask of the net. The IP address and optional network pairs are separated by slashes. Up to 10 pairs may be specified. Here is an example:

sortlist 130.155.160.0/255.255.240.0 130.155.0.0

options

Options allows certain internal resolver variables to be modified. The syntax is

options option ...

where option is one of the following:

debug

Sets RES_DEBUG in _res.options (effective only if glibc was built with debug support; see resolver(3)).

ndots:n

Sets a threshold for the number of dots which must appear in a name given to res_query(3) (see resolver(3)) before an initial absolute query will be made. The default for n is 1, meaning that if there are any dots in a name, the name will be tried first as an absolute name before any search list elements are appended to it. The value for this option is silently capped to 15.

timeout:n

Sets the amount of time the resolver will wait for a response from a remote name server before retrying the query via a different name server. This may not be the total time taken by any resolver API call and there is no guarantee that a single resolver API call maps to a single timeout. Measured in seconds, the default is RES_TIMEOUT (currently 5, see <resolv.h>). The value for this option is silently capped to 30.

attempts:n

Sets the number of times the resolver will send a query to its name servers before giving up and returning an error to the calling application. The default is RES_DFLRETRY (currently 2, see <resolv.h>). The value for this option is silently capped to 5.

rotate

Sets RES_ROTATE in _res.options, which causes round-robin selection of name servers from among those listed. This has the effect of spreading the query load among all listed servers, rather than having all clients try the first listed server first every time.

no-aaaa (since glibc 2.36)

Sets RES_NOAAAA in _res.options, which suppresses AAAA queries made by the stub resolver, including AAAA lookups triggered by NSS-based interfaces such as getaddrinfo(3). Only DNS lookups are affected: IPv6 data in hosts(5) is still used, getaddrinfo(3) with AI_PASSIVE will still produce IPv6 addresses, and configured IPv6 name servers are still used. To produce correct Name Error (NXDOMAIN) results, AAAA queries are translated to A queries. This option is intended preliminary for diagnostic purposes, to rule out that AAAA DNS queries have adverse impact. It is incompatible with EDNS0 usage and DNSSEC validation by applications.

no-check-names

Sets RES_NOCHECKNAME in _res.options, which disables the modern BIND checking of incoming hostnames and mail names for invalid characters such as underscore (_), non-ASCII, or control characters.

inet6

Sets RES_USE_INET6 in _res.options. This has the effect of trying an AAAA query before an A query inside the gethostbyname(3) function, and of mapping IPv4 responses in IPv6 "tunneled form" if no AAAA records are found but an A record set exists. Since glibc 2.25, this option is deprecated; applications should use getaddrinfo(3), rather than gethostbyname(3).

ip6-bytestring (since glibc 2.3.4 to glibc 2.24)

Sets RES_USEBSTRING in _res.options. This causes reverse IPv6 lookups to be made using the bit-label format described in RFC 2673; if this option is not set (which is the default), then nibble format is used. This option was removed in glibc 2.25, since it relied on a backward-incompatible DNS extension that was never deployed on the Internet.

ip6-dotint/no-ip6-dotint (glibc 2.3.4 to glibc 2.24)

Clear/set RES_NOIP6DOTINT in _res.options. When this option is clear (ip6-dotint), reverse IPv6 lookups are made in the (deprecated) ip6.int zone; when this option is set (no-ip6-dotint), reverse IPv6 lookups are made in the ip6.arpa zone by default. These options are available up to glibc 2.24, where no-ip6-dotint is the default. Since ip6-dotint support long ago ceased to be available on the Internet, these options were removed in glibc 2.25.

edns0 (since glibc 2.6)

Sets RES_USE_EDNS0 in _res.options. This enables support for the DNS extensions described in RFC 2671.

single-request (since glibc 2.10)

Sets RES_SNGLKUP in _res.options. By default, glibc performs IPv4 and IPv6 lookups in parallel since glibc 2.9. Some appliance DNS servers cannot handle these queries properly and make the requests time out. This option disables the behavior and makes glibc perform the IPv6 and IPv4 requests sequentially (at the cost of some slowdown of the resolving process).

single-request-reopen (since glibc 2.9)

Sets RES_SNGLKUPREOP in _res.options. The resolver uses the same socket for the A and AAAA requests. Some hardware mistakenly sends back only one reply. When that happens the client system will sit and wait for the second reply. Turning this option on changes this behavior so that if two requests from the same port are not handled correctly it will close the socket and open a new one before sending the second request.

no-tld-query (since glibc 2.14)

Sets RES_NOTLDQUERY in _res.options. This option causes res_nsearch() to not attempt to resolve an unqualified name as if it were a top level domain (TLD). This option can cause problems if the site has ``localhost'' as a TLD rather than having localhost on one or more elements of the search list. This option has no effect if neither RES_DEFNAMES or RES_DNSRCH is set.

use-vc (since glibc 2.14)

Sets RES_USEVC in _res.options. This option forces the use of TCP for DNS resolutions.

no-reload (since glibc 2.26)

Sets RES_NORELOAD in _res.options. This option disables automatic reloading of a changed configuration file.

trust-ad (since glibc 2.31)

Sets RES_TRUSTAD in _res.options. This option controls the AD bit behavior of the stub resolver. If a validating resolver sets the AD bit in a response, it indicates that the data in the response was verified according to the DNSSEC protocol. In order to rely on the AD bit, the local system has to trust both the DNSSEC-validating resolver and the network path to it, which is why an explicit opt-in is required. If the trust-ad option is active, the stub resolver sets the AD bit in outgoing DNS queries (to enable AD bit support), and preserves the AD bit in responses. Without this option, the AD bit is not set in queries, and it is always removed from responses before they are returned to the application. This means that applications can trust the AD bit in responses if the trust-ad option has been set correctly.

In glibc 2.30 and earlier, the AD is not set automatically in queries, and is passed through unchanged to applications in responses.

The search keyword of a system's resolv.conf file can be overridden on a per-process basis by setting the environment variable LOCALDOMAIN to a space-separated list of search domains.

The options keyword of a system's resolv.conf file can be amended on a per-process basis by setting the environment variable RES_OPTIONS to a space-separated list of resolver options as explained above under options.

The keyword and value must appear on a single line, and the keyword (e.g., nameserver) must start the line. The value follows the keyword, separated by white space.

Lines that contain a semicolon (;) or hash character (#) in the first column are treated as comments.

## FILES
/etc/resolv.conf, <resolv.h>

## SEE ALSO
gethostbyname(3), resolver(3), host.conf(5), hosts(5), nsswitch.conf(5), hostname(7), named(8)

Name Server Operations Guide for BIND


rpc

title: rpc(5)

summary: RPC program number data base

text:
# rpc(5)

## NAME
rpc - RPC program number data base

## SYNOPSIS

```
/etc/rpc
```

## DESCRIPTION
The rpc file contains user readable names that can be used in place of RPC program numbers. Each line has the following information:

•

name of server for the RPC program

•

RPC program number

•

aliases

Items are separated by any number of blanks and/or tab characters. A '#' indicates the beginning of a comment; characters from the '#' to the end of the line are not interpreted by routines which search the file.

Here is an example of the /etc/rpc file from the Sun RPC Source distribution.

```
#
# rpc 88/08/01 4.0 RPCSRC; from 1.12   88/02/07 SMI
#
portmapper      100000  portmap sunrpc
rstatd          100001  rstat rstat_svc rup perfmeter
rusersd         100002  rusers
nfs             100003  nfsprog
ypserv          100004  ypprog
mountd          100005  mount showmount
ypbind          100007
walld           100008  rwall shutdown
yppasswdd       100009  yppasswd
etherstatd      100010  etherstat
rquotad         100011  rquotaprog quota rquota
sprayd          100012  spray
3270_mapper     100013
rje_mapper      100014
selection_svc   100015  selnsvc
database_svc    100016
rexd            100017  rex
alis            100018
sched           100019
llockmgr        100020
nlockmgr        100021
x25.inr         100022
statmon         100023
status          100024
bootparam       100026
ypupdated       100028  ypupdate
keyserv         100029  keyserver
tfsd            100037
nsed            100038
nsemntd         100039
```

## FILES
/etc/rpc

RPC program number data base

## SEE ALSO
getrpcent(3)


securetty

title: securetty(5)

text:
# securetty(5)

## NAME
securetty - list of terminals on which root is allowed to login

## DESCRIPTION
The file /etc/securetty contains the names of terminals (one per line, without leading /dev/) which are considered secure for the transmission of certain authentication tokens.

It is used by (some versions of) login(1) to restrict the terminals on which root is allowed to login. See login.defs(5) if you use the shadow suite.

On PAM enabled systems, it is used for the same purpose by pam_securetty(8) to restrict the terminals on which empty passwords are accepted.

## FILES
/etc/securetty

## SEE ALSO
login(1), login.defs(5), pam_securetty(8)


services

title: services(5)

summary: Internet network services list

text:
# services(5)

## NAME
services - Internet network services list

## DESCRIPTION
services is a plain ASCII file providing a mapping between human-friendly textual names for internet services, and their underlying assigned port numbers and protocol types. Every networking program should look into this file to get the port number (and protocol) for its service. The C library routines getservent(3), getservbyname(3), getservbyport(3), setservent(3), and endservent(3) support querying this file from programs.

Port numbers are assigned by the IANA (Internet Assigned Numbers Authority), and their current policy is to assign both TCP and UDP protocols when assigning a port number. Therefore, most entries will have two entries, even for TCP-only services.

Port numbers below 1024 (so-called "low numbered" ports) can be bound to only by root (see bind(2), tcp(7), and udp(7)). This is so clients connecting to low numbered ports can trust that the service running on the port is the standard implementation, and not a rogue service run by a user of the machine. Well-known port numbers specified by the IANA are normally located in this root-only space.

The presence of an entry for a service in the services file does not necessarily mean that the service is currently running on the machine. See inetd.conf(5) for the configuration of Internet services offered. Note that not all networking services are started by inetd(8), and so won't appear in inetd.conf(5). In particular, news (NNTP) and mail (SMTP) servers are often initialized from the system boot scripts.

The location of the services file is defined by _PATH_SERVICES in <netdb.h>. This is usually set to /etc/services.

Each line describes one service, and is of the form:

service-name port/protocol [aliases ...]

where:

service-name

is the friendly name the service is known by and looked up under. It is case sensitive. Often, the client program is named after the service-name.

port

is the port number (in decimal) to use for this service.

protocol

is the type of protocol to be used. This field should match an entry in the protocols(5) file. Typical values include tcp and udp.

aliases

is an optional space or tab separated list of other names for this service. Again, the names are case sensitive.

Either spaces or tabs may be used to separate the fields.

Comments are started by the hash sign (#) and continue until the end of the line. Blank lines are skipped.

The service-name should begin in the first column of the file, since leading spaces are not stripped. service-names can be any printable characters excluding space and tab. However, a conservative choice of characters should be used to minimize compatibility problems. For example, a-z, 0-9, and hyphen (-) would seem a sensible choice.

Lines not matching this format should not be present in the file. (Currently, they are silently skipped by getservent(3), getservbyname(3), and getservbyport(3). However, this behavior should not be relied on.)

This file might be distributed over a network using a network-wide naming service like Yellow Pages/NIS or BIND/Hesiod.

A sample services file might look like this:

```
netstat         15/tcp
qotd            17/tcp          quote
msp             18/tcp          # message send protocol
msp             18/udp          # message send protocol
chargen         19/tcp          ttytst source
chargen         19/udp          ttytst source
ftp             21/tcp
# 22 - unassigned
telnet          23/tcp
```

## FILES
/etc/services

The Internet network services list

<netdb.h>

Definition of _PATH_SERVICES

## SEE ALSO
listen(2), endservent(3), getservbyname(3), getservbyport(3), getservent(3), setservent(3), inetd.conf(5), protocols(5), inetd(8)

Assigned Numbers RFC, most recently RFC 1700, (AKA STD0002).


shells

title: shells(5)

summary: pathnames of valid login shells

text:
# shells(5)

## NAME
shells - pathnames of valid login shells

## DESCRIPTION
/etc/shells is a text file which contains the full pathnames of valid login shells. This file is consulted by chsh(1) and available to be queried by other programs.

Be aware that there are programs which consult this file to find out if a user is a normal user; for example, FTP daemons traditionally disallow access to users with shells not included in this file.

## FILES
/etc/shells

## EXAMPLES
/etc/shells may contain the following paths:

```
/bin/sh
/bin/bash
/bin/csh
```

## SEE ALSO
chsh(1), getusershell(3), pam_shells(8)


slabinfo

title: slabinfo(5)

summary: kernel slab allocator statistics

text:
# slabinfo(5)

## NAME
slabinfo - kernel slab allocator statistics

## SYNOPSIS

```
cat /proc/slabinfo
```

## DESCRIPTION
Frequently used objects in the Linux kernel (buffer heads, inodes, dentries, etc.) have their own cache. The file /proc/slabinfo gives statistics on these caches. The following (edited) output shows an example of the contents of this file:

```
$ sudo cat /proc/slabinfo
slabinfo - version: 2.1
# name    <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> ...
sigqueue      100  100  160   25  1 : tunables  0  0  0 : slabdata   4   4  0
sighand_cache 355   405 2112  15  8 : tunables  0  0  0 : slabdata  27  27  0
kmalloc-8192   96   96  8192   4  8 : tunables  0  0  0 : slabdata  24  24  0
...
```

The first line of output includes a version number, which allows an application that is reading the file to handle changes in the file format. (See VERSIONS, below.) The next line lists the names of the columns in the remaining lines.

Each of the remaining lines displays information about a specified cache. Following the cache name, the output shown in each line shows three components for each cache:

•

statistics

•

tunables

•

slabdata

The statistics are as follows:

active_objs

The number of objects that are currently active (i.e., in use).

num_objs

The total number of allocated objects (i.e., objects that are both in use and not in use).

objsize

The size of objects in this slab, in bytes.

objperslab

The number of objects stored in each slab.

pagesperslab

The number of pages allocated for each slab.

The tunables entries in each line show tunable parameters for the corresponding cache. When using the default SLUB allocator, there are no tunables, the /proc/slabinfo file is not writable, and the value 0 is shown in these fields. When using the older SLAB allocator, the tunables for a particular cache can be set by writing lines of the following form to /proc/slabinfo:

```
# echo 'name limit batchcount sharedfactor' > /proc/slabinfo
```

Here, name is the cache name, and limit, batchcount, and sharedfactor are integers defining new values for the corresponding tunables. The limit value should be a positive value, batchcount should be a positive value that is less than or equal to limit, and sharedfactor should be nonnegative. If any of the specified values is invalid, the cache settings are left unchanged.

The tunables entries in each line contain the following fields:

limit

The maximum number of objects that will be cached.

batchcount

On SMP systems, this specifies the number of objects to transfer at one time when refilling the available object list.

sharedfactor

[To be documented]

The slabdata entries in each line contain the following fields:

active_slabs

The number of active slabs.

nums_slabs

The total number of slabs.

sharedavail

[To be documented]

Note that because of object alignment and slab cache overhead, objects are not normally packed tightly into pages. Pages with even one in-use object are considered in-use and cannot be freed.

Kernels configured with CONFIG_DEBUG_SLAB will also have additional statistics fields in each line, and the first line of the file will contain the string "(statistics)". The statistics field include : the high water mark of active objects; the number of times objects have been allocated; the number of times the cache has grown (new pages added to this cache); the number of times the cache has been reaped (unused pages removed from this cache); and the number of times there was an error allocating new pages to this cache.

## VERSIONS
The /proc/slabinfo file first appeared in Linux 2.1.23. The file is versioned, and over time there have been a number of versions with different layouts:

1.0

Present throughout the Linux 2.2.x kernel series.

1.1

Present in the Linux 2.4.x kernel series.

1.2

A format that was briefly present in the Linux 2.5 development series.

2.0

Present in Linux 2.6.x kernels up to and including Linux 2.6.9.

2.1

The current format, which first appeared in Linux 2.6.10.

## NOTES
Only root can read and (if the kernel was configured with CONFIG_SLAB) write the /proc/slabinfo file.

The total amount of memory allocated to the SLAB/SLUB cache is shown in the Slab field of /proc/meminfo.

## SEE ALSO
slabtop(1)

The kernel source file Documentation/vm/slub.txt and tools/vm/slabinfo.c.


sysfs

title: sysfs(5)

text:
# sysfs(5)

## NAME
sysfs - a filesystem for exporting kernel objects

## DESCRIPTION
The sysfs filesystem is a pseudo-filesystem which provides an interface to kernel data structures. (More precisely, the files and directories in sysfs provide a view of the kobject structures defined internally within the kernel.) The files under sysfs provide information about devices, kernel modules, filesystems, and other kernel components.

The sysfs filesystem is commonly mounted at /sys. Typically, it is mounted automatically by the system, but it can also be mounted manually using a command such as:

```
mount -t sysfs sysfs /sys
```

Many of the files in the sysfs filesystem are read-only, but some files are writable, allowing kernel variables to be changed. To avoid redundancy, symbolic links are heavily used to connect entries across the filesystem tree.

### Files and directories
The following list describes some of the files and directories under the /sys hierarchy.

/sys/block

This subdirectory contains one symbolic link for each block device that has been discovered on the system. The symbolic links point to corresponding directories under /sys/devices.

/sys/bus

This directory contains one subdirectory for each of the bus types in the kernel. Inside each of these directories are two subdirectories:

devices

This subdirectory contains symbolic links to entries in /sys/devices that correspond to the devices discovered on this bus.

drivers

This subdirectory contains one subdirectory for each device driver that is loaded on this bus.

/sys/class

This subdirectory contains a single layer of further subdirectories for each of the device classes that have been registered on the system (e.g., terminals, network devices, block devices, graphics devices, sound devices, and so on). Inside each of these subdirectories are symbolic links for each of the devices in this class. These symbolic links refer to entries in the /sys/devices directory.

/sys/class/net

Each of the entries in this directory is a symbolic link representing one of the real or virtual networking devices that are visible in the network namespace of the process that is accessing the directory. Each of these symbolic links refers to entries in the /sys/devices directory.

/sys/dev

This directory contains two subdirectories block/ and char/, corresponding, respectively, to the block and character devices on the system. Inside each of these subdirectories are symbolic links with names of the form major-ID:minor-ID, where the ID values correspond to the major and minor ID of a specific device. Each symbolic link points to the sysfs directory for a device. The symbolic links inside /sys/dev thus provide an easy way to look up the sysfs interface using the device IDs returned by a call to stat(2) (or similar).

The following shell session shows an example from /sys/dev:

```
$ stat -c "%t %T" /dev/null
1 3
$ readlink /sys/dev/char/1\:3
../../devices/virtual/mem/null
$ ls -Fd /sys/devices/virtual/mem/null
/sys/devices/virtual/mem/null/
$ ls -d1 /sys/devices/virtual/mem/null/*
/sys/devices/virtual/mem/null/dev
/sys/devices/virtual/mem/null/power/
/sys/devices/virtual/mem/null/subsystem@
/sys/devices/virtual/mem/null/uevent

```

/sys/devices

This is a directory that contains a filesystem representation of the kernel device tree, which is a hierarchy of device structures within the kernel.

/sys/firmware

This subdirectory contains interfaces for viewing and manipulating firmware-specific objects and attributes.

/sys/fs

This directory contains subdirectories for some filesystems. A filesystem will have a subdirectory here only if it chose to explicitly create the subdirectory.

/sys/fs/cgroup

This directory conventionally is used as a mount point for a tmpfs(5) filesystem containing mount points for cgroups(7) filesystems.

/sys/fs/smackfs

The directory contains configuration files for the SMACK LSM. See the kernel source file Documentation/admin-guide/LSM/Smack.rst.

/sys/hypervisor

[To be documented]

/sys/kernel

This subdirectory contains various files and subdirectories that provide information about the running kernel.

/sys/kernel/cgroup/

For information about the files in this directory, see cgroups(7).

/sys/kernel/debug/tracing

Mount point for the tracefs filesystem used by the kernel's ftrace facility. (For information on ftrace, see the kernel source file Documentation/trace/ftrace.txt.)

/sys/kernel/mm

This subdirectory contains various files and subdirectories that provide information about the kernel's memory management subsystem.

/sys/kernel/mm/hugepages

This subdirectory contains one subdirectory for each of the huge page sizes that the system supports. The subdirectory name indicates the huge page size (e.g., hugepages-2048kB). Within each of these subdirectories is a set of files that can be used to view and (in some cases) change settings associated with that huge page size. For further information, see the kernel source file Documentation/admin-guide/mm/hugetlbpage.rst.

/sys/module

This subdirectory contains one subdirectory for each module that is loaded into the kernel. The name of each directory is the name of the module. In each of the subdirectories, there may be following files:

coresize

[to be documented]

initsize

[to be documented]

initstate

[to be documented]

refcnt

[to be documented]

srcversion

[to be documented]

taint

[to be documented]

uevent

[to be documented]

version

[to be documented]

In each of the subdirectories, there may be following subdirectories:

drivers

[To be documented]

holders

[To be documented]

notes

[To be documented]

parameters

This directory contains one file for each module parameter, with each file containing the value of the corresponding parameter. Some of these files are writable, allowing the

sections

This subdirectories contains files with information about module sections. This information is mainly used for debugging.

[To be documented]

/sys/power

[To be documented]

## STANDARDS
Linux.

## HISTORY
Linux 2.6.0.

## NOTES
This manual page is incomplete, possibly inaccurate, and is the kind of thing that needs to be updated very often.

## SEE ALSO
proc(5), udev(7)

P. Mochel. (2005). The sysfs filesystem. Proceedings of the 2005 Ottawa Linux Symposium.

The kernel source file Documentation/filesystems/sysfs.txt and various other files in Documentation/ABI and Documentation/*/sysfs.txt


termcap

title: termcap(5)

summary: terminal capability database

text:
# termcap(5)

## NAME
termcap - terminal capability database

## DESCRIPTION
The termcap database is an obsolete facility for describing the capabilities of character-cell terminals and printers. It is retained only for compatibility with old programs; new programs should use the terminfo(5) database and associated libraries.

/etc/termcap is an ASCII file (the database master) that lists the capabilities of many different types of terminals. Programs can read termcap to find the particular escape codes needed to control the visual attributes of the terminal actually in use. (Other aspects of the terminal are handled by stty(1).) The termcap database is indexed on the TERM environment variable.

Termcap entries must be defined on a single logical line, with '\' used to suppress the newline. Fields are separated by ':'. The first field of each entry starts at the left-hand margin, and contains a list of names for the terminal, separated by '|'.

The first subfield may (in BSD termcap entries from 4.3BSD and earlier) contain a short name consisting of two characters. This short name may consist of capital or small letters. In 4.4BSD, termcap entries this field is omitted.

The second subfield (first, in the newer 4.4BSD format) contains the name used by the environment variable TERM. It should be spelled in lowercase letters. Selectable hardware capabilities should be marked by appending a hyphen and a suffix to this name. See below for an example. Usual suffixes are w (more than 80 characters wide), am (automatic margins), nam (no automatic margins), and rv (reverse video display). The third subfield contains a long and descriptive name for this termcap entry.

Subsequent fields contain the terminal capabilities; any continued capability lines must be indented one tab from the left margin.

Although there is no defined order, it is suggested to write first boolean, then numeric, and then string capabilities, each sorted alphabetically without looking at lower or upper spelling. Capabilities of similar functions can be written in one line.

Example for:

```
Head line: vt|vt101|DEC VT 101 terminal in 80 character mode:\
Head line: Vt|vt101-w|DEC VT 101 terminal in (wide) 132 character mode:\
Boolean: :bs:\
Numeric: :co#80:\
String: :sr=\E[H:\
```

### Boolean capabilities

```
5i	Printer will not echo on screen
am	Automatic margins which means automatic line wrap
bs	Control-H (8 dec.) performs a backspace
bw	Backspace on left margin wraps to previous line and right margin
da	Display retained above screen
db	Display retained below screen
eo	A space erases all characters at cursor position
es	Escape sequences and special characters work in status line
gn	Generic device
hc	This is a hardcopy terminal
HC	The cursor is hard to see when not on bottom line
hs	Has a status line
hz	Hazeltine bug, the terminal can not print tilde characters
in	Terminal inserts null bytes, not spaces, to fill whitespace
km	Terminal has a meta key
mi	Cursor movement works in insert mode
ms	Cursor movement works in standout/underline mode
NP	No pad character
NR	ti does not reverse te
nx	No padding, must use XON/XOFF
os	Terminal can overstrike
ul	Terminal underlines although it can not overstrike
xb	Beehive glitch, f1 sends ESCAPE, f2 sends ^C
xn	Newline/wraparound glitch
xo	Terminal uses xon/xoff protocol
xs	Text typed over standout text will be displayed in standout
xt	Teleray glitch, destructive tabs and odd standout mode
```

### Numeric capabilities

```
co	Number of columns
dB	Delay in milliseconds for backspace on hardcopy terminals
dC	Delay in milliseconds for carriage return on hardcopy terminals
dF	Delay in milliseconds for form feed on hardcopy terminals
dN	Delay in milliseconds for new line on hardcopy terminals
dT	Delay in milliseconds for tabulator stop on hardcopy terminals
dV	Delay in milliseconds for vertical tabulator stop on
	hardcopy terminals
it	Difference between tab positions
lh	Height of soft labels
lm	Lines of memory
lw	Width of soft labels
li	Number of lines
Nl	Number of soft labels
pb	Lowest baud rate which needs padding
sg	Standout glitch
ug	Underline glitch
vt	virtual terminal number
ws	Width of status line if different from screen width
```

### String capabilities

```
!1	shifted save key
!2	shifted suspend key
!3	shifted undo key
#1	shifted help key
#2	shifted home key
#3	shifted input key
#4	shifted cursor left key
%0	redo key
%1	help key
%2	mark key
%3	message key
%4	move key
%5	next-object key
%6	open key
%7	options key
%8	previous-object key
%9	print key
%a	shifted message key
%b	shifted move key
%c	shifted next key
%d	shifted options key
%e	shifted previous key
%f	shifted print key
%g	shifted redo key
%h	shifted replace key
%i	shifted cursor right key
%j	shifted resume key
&0	shifted cancel key
&1	reference key
&2	refresh key
&3	replace key
&4	restart key
&5	resume key
&6	save key
&7	suspend key
&8	undo key
&9	shifted begin key
*0	shifted find key
*1	shifted command key
*2	shifted copy key
*3	shifted create key
*4	shifted delete character
*5	shifted delete line
*6	select key
*7	shifted end key
*8	shifted clear line key
*9	shifted exit key
@0	find key
@1	begin key
@2	cancel key
@3	close key
@4	command key
@5	copy key
@6	create key
@7	end key
@8	enter/send key
@9	exit key
al	Insert one line
AL	Insert %1 lines
ac	Pairs of block graphic characters to map alternate character set
ae	End alternative character set
as	Start alternative character set for block graphic characters
bc	Backspace, if not ^H
bl	Audio bell
bt	Move to previous tab stop
cb	Clear from beginning of line to cursor
cc	Dummy command character
cd	Clear to end of screen
ce	Clear to end of line
ch	Move cursor horizontally only to column %1
cl	Clear screen and cursor home
cm	Cursor move to row %1 and column %2 (on screen)
CM	Move cursor to row %1 and column %2 (in memory)
cr	Carriage return
cs	Scroll region from line %1 to %2
ct	Clear tabs
cv	Move cursor vertically only to line %1
dc	Delete one character
DC	Delete %1 characters
dl	Delete one line
DL	Delete %1 lines
dm	Begin delete mode
do	Cursor down one line
DO	Cursor down #1 lines
ds	Disable status line
eA	Enable alternate character set
ec	Erase %1 characters starting at cursor
ed	End delete mode
ei	End insert mode
ff	Formfeed character on hardcopy terminals
fs	Return character to its position before going to status line
F1	The string sent by function key f11
F2	The string sent by function key f12
F3	The string sent by function key f13
...	...
F9	The string sent by function key f19
FA	The string sent by function key f20
FB	The string sent by function key f21
...	...
FZ	The string sent by function key f45
Fa	The string sent by function key f46
Fb	The string sent by function key f47
...	...
Fr	The string sent by function key f63
hd	Move cursor a half line down
ho	Cursor home
hu	Move cursor a half line up
i1	Initialization string 1 at login
i3	Initialization string 3 at login
is	Initialization string 2 at login
ic	Insert one character
IC	Insert %1 characters
if	Initialization file
im	Begin insert mode
ip	Insert pad time and needed special characters after insert
iP	Initialization program
K1	upper left key on keypad
K2	center key on keypad
K3	upper right key on keypad
K4	bottom left key on keypad
K5	bottom right key on keypad
k0	Function key 0
k1	Function key 1
k2	Function key 2
k3	Function key 3
k4	Function key 4
k5	Function key 5
k6	Function key 6
k7	Function key 7
k8	Function key 8
k9	Function key 9
k;	Function key 10
ka	Clear all tabs key
kA	Insert line key
kb	Backspace key
kB	Back tab stop
kC	Clear screen key
kd	Cursor down key
kD	Key for delete character under cursor
ke	turn keypad off
kE	Key for clear to end of line
kF	Key for scrolling forward/down
kh	Cursor home key
kH	Cursor hown down key
kI	Insert character/Insert mode key
kl	Cursor left key
kL	Key for delete line
kM	Key for exit insert mode
kN	Key for next page
kP	Key for previous page
kr	Cursor right key
kR	Key for scrolling backward/up
ks	Turn keypad on
kS	Clear to end of screen key
kt	Clear this tab key
kT	Set tab here key
ku	Cursor up key
l0	Label of zeroth function key, if not f0
l1	Label of first function key, if not f1
l2	Label of first function key, if not f2
...	...
la	Label of tenth function key, if not f10
le	Cursor left one character
ll	Move cursor to lower left corner
LE	Cursor left %1 characters
LF	Turn soft labels off
LO	Turn soft labels on
mb	Start blinking
MC	Clear soft margins
md	Start bold mode
me	End all mode like so, us, mb, md, and mr
mh	Start half bright mode
mk	Dark mode (Characters invisible)
ML	Set left soft margin
mm	Put terminal in meta mode
mo	Put terminal out of meta mode
mp	Turn on protected attribute
mr	Start reverse mode
MR	Set right soft margin
nd	Cursor right one character
nw	Carriage return command
pc	Padding character
pf	Turn printer off
pk	Program key %1 to send string %2 as if typed by user
pl	Program key %1 to execute string %2 in local mode
pn	Program soft label %1 to show string %2
po	Turn the printer on
pO	Turn the printer on for %1 (<256) bytes
ps	Print screen contents on printer
px	Program key %1 to send string %2 to computer
r1	Reset string 1 to set terminal to sane modes
r2	Reset string 2 to set terminal to sane modes
r3	Reset string 3 to set terminal to sane modes
RA	disable automatic margins
rc	Restore saved cursor position
rf	Reset string filename
RF	Request for input from terminal
RI	Cursor right %1 characters
rp	Repeat character %1 for %2 times
rP	Padding after character sent in replace mode
rs	Reset string
RX	Turn off XON/XOFF flow control
sa	Set %1 %2 %3 %4 %5 %6 %7 %8 %9 attributes
SA	enable automatic margins
sc	Save cursor position
se	End standout mode
sf	Normal scroll one line
SF	Normal scroll %1 lines
so	Start standout mode
sr	Reverse scroll
SR	scroll back %1 lines
st	Set tabulator stop in all rows at current column
SX	Turn on XON/XOFF flow control
ta	move to next hardware tab
tc	Read in terminal description from another entry
te	End program that uses cursor motion
ti	Begin program that uses cursor motion
ts	Move cursor to column %1 of status line
uc	Underline character under cursor and move cursor right
ue	End underlining
up	Cursor up one line
UP	Cursor up %1 lines
us	Start underlining
vb	Visible bell
ve	Normal cursor visible
vi	Cursor invisible
vs	Standout cursor
wi	Set window from line %1 to %2 and column %3 to %4
XF	XOFF character if not ^S
```

There are several ways of defining the control codes for string capabilities:

Every normal character represents itself, except '^', '\', and '%'.

A ^x means Control-x. Control-A equals 1 decimal.

\x means a special code. x can be one of the following characters:

E Escape (27)

n Linefeed (10)

r Carriage return (13)

t Tabulation (9)

b Backspace (8)

f Form feed (12)

0 Null character. A \xxx specifies the octal character xxx.

i

Increments parameters by one.

r

Single parameter capability

+

Add value of next character to this parameter and do binary output

2

Do ASCII output of this parameter with a field with of 2

d

Do ASCII output of this parameter with a field with of 3

%

Print a '%'

If you use binary output, then you should avoid the null character ('\0') because it terminates the string. You should reset tabulator expansion if a tabulator can be the binary output of a parameter.

Warning:

The above metacharacters for parameters may be wrong: they document Minix termcap which may not be compatible with Linux termcap.

The block graphic characters can be specified by three string capabilities:

as

start the alternative charset

ae

end the alternative charset

ac

pairs of characters. The first character is the name of the block graphic symbol and the second characters is its definition.

The following names are available:

```
+	right arrow (>)
,	left arrow (<)
.	down arrow (v)
0	full square (#)
I	lantern (#)
-	upper arrow (^)
'	rhombus (+)
a	chess board (:)
f	degree (')
g	plus-minus (#)
h	square (#)
j	right bottom corner (+)
k	right upper corner (+)
l	left upper corner (+)
m	left bottom corner (+)
n	cross (+)
o	upper horizontal line (-)
q	middle horizontal line (-)
s	bottom horizontal line (_)
t	left tee (+)
u	right tee (+)
v	bottom tee (+)
w	normal tee (+)
x	vertical line (|)
~	paragraph (???)
```

The values in parentheses are suggested defaults which are used by the curses library, if the capabilities are missing.

## SEE ALSO
ncurses(3), termcap(3), terminfo(5)


tmpfs

title: tmpfs(5)

summary: a virtual memory filesystem

text:
# tmpfs(5)

## NAME
tmpfs - a virtual memory filesystem

## DESCRIPTION
The tmpfs facility allows the creation of filesystems whose contents reside in virtual memory. Since the files on such filesystems typically reside in RAM, file access is extremely fast.

The filesystem is automatically created when mounting a filesystem with the type tmpfs via a command such as the following:

```
$ sudo mount -t tmpfs -o size=10M tmpfs /mnt/mytmpfs
```

A tmpfs filesystem has the following properties:

•

The filesystem can employ swap space when physical memory pressure demands it.

•

The filesystem consumes only as much physical memory and swap space as is required to store the current contents of the filesystem.

•

During a remount operation (mount -o remount), the filesystem size can be changed (without losing the existing contents of the filesystem).

If a tmpfs filesystem is unmounted, its contents are discarded (lost).

### Mount options
The tmpfs filesystem supports the following mount options:

size=bytes

Specify an upper limit on the size of the filesystem. The size is given in bytes, and rounded up to entire pages.

The size may have a k, m, or g suffix for Ki, Mi, Gi (binary kilo (kibi), binary mega (mebi), and binary giga (gibi)).

The size may also have a % suffix to limit this instance to a percentage of physical RAM.

The default, when neither size nor nr_blocks is specified, is size=50%.

nr_blocks=blocks

The same as size, but in blocks of PAGE_CACHE_SIZE.

Blocks may be specified with k, m, or g suffixes like size, but not a % suffix.

nr_inodes=inodes

The maximum number of inodes for this instance. The default is half of the number of your physical RAM pages, or (on a machine with highmem) the number of lowmem RAM pages, whichever is smaller.

Inodes may be specified with k, m, or g suffixes like size, but not a % suffix.

mode=mode

Set initial permissions of the root directory.

gid=gid (since Linux 2.5.7)

Set the initial group ID of the root directory.

uid=uid (since Linux 2.5.7)

Set the initial user ID of the root directory.

huge=huge_option (since Linux 4.7.0)

Set the huge table memory allocation policy for all files in this instance (if CONFIG_TRANSPARENT_HUGEPAGE is enabled).

The huge_option value is one of the following:

never

Do not allocate huge pages. This is the default.

always

Attempt to allocate huge pages every time a new page is needed.

within_size

Only allocate huge page if it will be fully within i_size. Also respect fadvise(2) and madvise(2) hints

advise

Only allocate huge pages if requested with fadvise(2) or madvise(2).

deny

For use in emergencies, to force the huge option off from all mounts.

force

Force the huge option on for all mounts; useful for testing.

mpol=mpol_option (since Linux 2.6.15)

Set the NUMA memory allocation policy for all files in this instance (if CONFIG_NUMA is enabled).

The mpol_option value is one of the following:

default

Use the process allocation policy (see set_mempolicy(2)).

prefer:node

Preferably allocate memory from the given node.

bind:nodelist

Allocate memory only from nodes in nodelist.

interleave

Allocate from each node in turn.

interleave:nodelist

Allocate from each node of in turn.

local

Preferably allocate memory from the local node.

In the above, nodelist is a comma-separated list of decimal numbers and ranges that specify NUMA nodes. A range is a pair of hyphen-separated decimal numbers, the smallest and largest node numbers in the range. For example, mpol=bind:0-3,5,7,9-15.

## VERSIONS
The tmpfs facility was added in Linux 2.4, as a successor to the older ramfs facility, which did not provide limit checking or allow for the use of swap space.

## NOTES
In order for user-space tools and applications to create tmpfs filesystems, the kernel must be configured with the CONFIG_TMPFS option.

The tmpfs filesystem supports extended attributes (see xattr(7)), but user extended attributes are not permitted.

An internal shared memory filesystem is used for System V shared memory (shmget(2)) and shared anonymous mappings (mmap(2) with the MAP_SHARED and MAP_ANONYMOUS flags). This filesystem is available regardless of whether the kernel was configured with the CONFIG_TMPFS option.

A tmpfs filesystem mounted at /dev/shm is used for the implementation of POSIX shared memory (shm_overview(7)) and POSIX semaphores (sem_overview(7)).

The amount of memory consumed by all tmpfs filesystems is shown in the Shmem field of /proc/meminfo and in the shared field displayed by free(1).

The tmpfs facility was formerly called shmfs.

## SEE ALSO
df(1), du(1), memfd_create(2), mmap(2), set_mempolicy(2), shm_open(3), mount(8)

The kernel source files Documentation/filesystems/tmpfs.txt and Documentation/admin-guide/mm/transhuge.rst.


ttytype

title: ttytype(5)

text:
# ttytype(5)

## NAME
ttytype - terminal device to default terminal type mapping

## DESCRIPTION
The /etc/ttytype file associates termcap(5) and terminfo(5) terminal type names with tty lines. Each line consists of a terminal type, followed by whitespace, followed by a tty name (a device name without the /dev/ prefix).

This association is used by the program tset(1) to set the environment variable TERM to the default terminal name for the user's current tty.

This facility was designed for a traditional time-sharing environment featuring character-cell terminals hardwired to a UNIX minicomputer. It is little used on modern workstation and personal UNIX systems.

## FILES
/etc/ttytype

the tty definitions file.

## EXAMPLES
A typical /etc/ttytype is:

```
con80x25 tty1
vt320 ttys0
```

## SEE ALSO
termcap(5), terminfo(5), agetty(8), mingetty(8)


tzfile

title: tzfile(5)

summary: timezone information

text:
# tzfile(5)

## NAME
tzfile - timezone information

## DESCRIPTION
The timezone information files used by tzset(3) are typically found under a directory with a name like /usr/share/zoneinfo. These files use the format described in Internet RFC 8536. Each file is a sequence of 8-bit bytes. In a file, a binary integer is represented by a sequence of one or more bytes in network order (bigendian, or high-order byte first), with all bits significant, a signed binary integer is represented using two's complement, and a boolean is represented by a one-byte binary integer that is either 0 (false) or 1 (true). The format begins with a 44-byte header containing the following fields:

- The magic four-byte ASCII sequence “TZif” identifies the file as a timezone information file.

- A byte identifying the version of the file's format (as of 2021, either an ASCII NUL, “2”, “3”, or “4”).

- Fifteen bytes containing zeros reserved for future use.

- Six four-byte integer values, in the following order:

tzh_ttisutcnt

The number of UT/local indicators stored in the file. (UT is Universal Time.)

tzh_ttisstdcnt

The number of standard/wall indicators stored in the file.

tzh_leapcnt

The number of leap seconds for which data entries are stored in the file.

tzh_timecnt

The number of transition times for which data entries are stored in the file.

tzh_typecnt

The number of local time types for which data entries are stored in the file (must not be zero).

tzh_charcnt

The number of bytes of time zone abbreviation strings stored in the file.

The above header is followed by the following fields, whose lengths depend on the contents of the header:

- tzh_timecnt four-byte signed integer values sorted in ascending order. These values are written in network byte order. Each is used as a transition time (as returned by time(2)) at which the rules for computing local time change.

- tzh_timecnt one-byte unsigned integer values; each one but the last tells which of the different types of local time types described in the file is associated with the time period starting with the same-indexed transition time and continuing up to but not including the next transition time. (The last time type is present only for consistency checking with the POSIX-style TZ string described below.) These values serve as indices into the next field.

- tzh_typecnt ttinfo entries, each defined as follows:

```
struct ttinfo {
	int32_t	tt_utoff;
	unsigned char	tt_isdst;
	unsigned char	tt_desigidx;
};

```

Each structure is written as a four-byte signed integer value for tt_utoff, in network byte order, followed by a one-byte boolean for tt_isdst and a one-byte value for tt_desigidx. In each structure, tt_utoff gives the number of seconds to be added to UT, tt_isdst tells whether tm_isdst should be set by localtime(3) and tt_desigidx serves as an index into the array of time zone abbreviation bytes that follow the ttinfo entries in the file; if the designated string is "-00", the ttinfo entry is a placeholder indicating that local time is unspecified. The tt_utoff value is never equal to -2**31, to let 32-bit clients negate it without overflow. Also, in realistic applications tt_utoff is in the range [-89999, 93599] (i.e., more than -25 hours and less than 26 hours); this allows easy support by implementations that already support the POSIX-required range [-24:59:59, 25:59:59].

- tzh_charcnt bytes that represent time zone designations, which are null-terminated byte strings, each indexed by the tt_desigidx values mentioned above. The byte strings can overlap if one is a suffix of the other. The encoding of these strings is not specified.

- tzh_leapcnt pairs of four-byte values, written in network byte order; the first value of each pair gives the nonnegative time (as returned by time(2)) at which a leap second occurs or at which the leap second table expires; the second is a signed integer specifying the correction, which is the total number of leap seconds to be applied during the time period starting at the given time. The pairs of values are sorted in strictly ascending order by time. Each pair denotes one leap second, either positive or negative, except that if the last pair has the same correction as the previous one, the last pair denotes the leap second table's expiration time. Each leap second is at the end of a UTC calendar month. The first leap second has a nonnegative occurrence time, and is a positive leap second if and only if its correction is positive; the correction for each leap second after the first differs from the previous leap second by either 1 for a positive leap second, or -1 for a negative leap second. If the leap second table is empty, the leap-second correction is zero for all timestamps; otherwise, for timestamps before the first occurrence time, the leap-second correction is zero if the first pair's correction is 1 or -1, and is unspecified otherwise (which can happen only in files truncated at the start).

- tzh_ttisstdcnt standard/wall indicators, each stored as a one-byte boolean; they tell whether the transition times associated with local time types were specified as standard time or local (wall clock) time.

- tzh_ttisutcnt UT/local indicators, each stored as a one-byte boolean; they tell whether the transition times associated with local time types were specified as UT or local time. If a UT/local indicator is set, the corresponding standard/wall indicator must also be set.

The standard/wall and UT/local indicators were designed for transforming a TZif file's transition times into transitions appropriate for another time zone specified via a POSIX-style TZ string that lacks rules. For example, when TZ="EET-2EEST" and there is no TZif file "EET-2EEST", the idea was to adapt the transition times from a TZif file with the well-known name "posixrules" that is present only for this purpose and is a copy of the file "Europe/Brussels", a file with a different UT offset. POSIX does not specify this obsolete transformational behavior, the default rules are installation-dependent, and no implementation is known to support this feature for timestamps past 2037, so users desiring (say) Greek time should instead specify TZ="Europe/Athens" for better historical coverage, falling back on TZ="EET-2EEST,M3.5.0/3,M10.5.0/4" if POSIX conformance is required and older timestamps need not be handled accurately.

The localtime(3) function normally uses the first ttinfo structure in the file if either tzh_timecnt is zero or the time argument is less than the first transition time recorded in the file.

### Version 2 format
For version-2-format timezone files, the above header and data are followed by a second header and data, identical in format except that eight bytes are used for each transition time or leap second time. (Leap second counts remain four bytes.) After the second header and data comes a newline-enclosed, POSIX-TZ-environment-variable-style string for use in handling instants after the last transition time stored in the file or for all instants if the file has no transitions. The POSIX-style TZ string is empty (i.e., nothing between the newlines) if there is no POSIX-style representation for such instants. If nonempty, the POSIX-style TZ string must agree with the local time type after the last transition time if present in the eight-byte data; for example, given the string “WET0WEST,M3.5.0/1,M10.5.0” then if a last transition time is in July, the transition's local time type must specify a daylight-saving time abbreviated “WEST” that is one hour east of UT. Also, if there is at least one transition, time type 0 is associated with the time period from the indefinite past up to but not including the earliest transition time.

### Version 3 format
For version-3-format timezone files, the POSIX-TZ-style string may use two minor extensions to the POSIX TZ format, as described in newtzset(3). First, the hours part of its transition times may be signed and range from -167 through 167 instead of the POSIX-required unsigned values from 0 through 24. Second, DST is in effect all year if it starts January 1 at 00:00 and ends December 31 at 24:00 plus the difference between daylight saving and standard time.

### Version 4 format
For version-4-format TZif files, the first leap second record can have a correction that is neither +1 nor -1, to represent truncation of the TZif file at the start. Also, if two or more leap second transitions are present and the last entry's correction equals the previous one, the last entry denotes the expiration of the leap second table instead of a leap second; timestamps after this expiration are unreliable in that future releases will likely add leap second entries after the expiration, and the added leap seconds will change how post-expiration timestamps are treated.

### Interoperability considerations
Future changes to the format may append more data.

Version 1 files are considered a legacy format and should not be generated, as they do not support transition times after the year 2038. Readers that understand only Version 1 must ignore any data that extends beyond the calculated end of the version 1 data block.

Other than version 1, writers should generate the lowest version number needed by a file's data. For example, a writer should generate a version 4 file only if its leap second table either expires or is truncated at the start. Likewise, a writer not generating a version 4 file should generate a version 3 file only if TZ string extensions are necessary to accurately model transition times.

The sequence of time changes defined by the version 1 header and data block should be a contiguous sub-sequence of the time changes defined by the version 2+ header and data block, and by the footer. This guideline helps obsolescent version 1 readers agree with current readers about timestamps within the contiguous sub-sequence. It also lets writers not supporting obsolescent readers use a tzh_timecnt of zero in the version 1 data block to save space.

When a TZif file contains a leap second table expiration time, TZif readers should either refuse to process post-expiration timestamps, or process them as if the expiration time did not exist (possibly with an error indication).

Time zone designations should consist of at least three (3) and no more than six (6) ASCII characters from the set of alphanumerics, “-”, and “+”. This is for compatibility with POSIX requirements for time zone abbreviations.

When reading a version 2 or higher file, readers should ignore the version 1 header and data block except for the purpose of skipping over them.

Readers should calculate the total lengths of the headers and data blocks and check that they all fit within the actual file size, as part of a validity check for the file.

When a positive leap second occurs, readers should append an extra second to the local minute containing the second just before the leap second. If this occurs when the UTC offset is not a multiple of 60 seconds, the leap second occurs earlier than the last second of the local minute and the minute's remaining local seconds are numbered through 60 instead of the usual 59; the UTC offset is unaffected.

### Common interoperability issues
This section documents common problems in reading or writing TZif files. Most of these are problems in generating TZif files for use by older readers. The goals of this section are:

- to help TZif writers output files that avoid common pitfalls in older or buggy TZif readers,

- to help TZif readers avoid common pitfalls when reading files generated by future TZif writers, and

- to help any future specification authors see what sort of problems arise when the TZif format is changed.

When new versions of the TZif format have been defined, a design goal has been that a reader can successfully use a TZif file even if the file is of a later TZif version than what the reader was designed for. When complete compatibility was not achieved, an attempt was made to limit glitches to rarely used timestamps and allow simple partial workarounds in writers designed to generate new-version data useful even for older-version readers. This section attempts to document these compatibility issues and workarounds, as well as to document other common bugs in readers.

Interoperability problems with TZif include the following:

- Some readers examine only version 1 data. As a partial workaround, a writer can output as much version 1 data as possible. However, a reader should ignore version 1 data, and should use version 2+ data even if the reader's native timestamps have only 32 bits.

- Some readers designed for version 2 might mishandle timestamps after a version 3 or higher file's last transition, because they cannot parse extensions to POSIX in the TZ-like string. As a partial workaround, a writer can output more transitions than necessary, so that only far-future timestamps are mishandled by version 2 readers.

- Some readers designed for version 2 do not support permanent daylight saving time with transitions after 24:00 – e.g., a TZ string “EST5EDT,0/0,J365/25” denoting permanent Eastern Daylight Time (-04). As a workaround, a writer can substitute standard time for two time zones east, e.g., “XXX3EDT4,0/0,J365/23” for a time zone with a never-used standard time (XXX, -03) and negative daylight saving time (EDT, -04) all year. Alternatively, as a partial workaround a writer can substitute standard time for the next time zone east – e.g., “AST4” for permanent Atlantic Standard Time (-04).

- Some readers designed for version 2 or 3, and that require strict conformance to RFC 8536, reject version 4 files whose leap second tables are truncated at the start or that end in expiration times.

- Some readers ignore the footer, and instead predict future timestamps from the time type of the last transition. As a partial workaround, a writer can output more transitions than necessary.

- Some readers do not use time type 0 for timestamps before the first transition, in that they infer a time type using a heuristic that does not always select time type 0. As a partial workaround, a writer can output a dummy (no-op) first transition at an early time.

- Some readers mishandle timestamps before the first transition that has a timestamp not less than -2**31. Readers that support only 32-bit timestamps are likely to be more prone to this problem, for example, when they process 64-bit transitions only some of which are representable in 32 bits. As a partial workaround, a writer can output a dummy transition at timestamp -2**31.

- Some readers mishandle a transition if its timestamp has the minimum possible signed 64-bit value. Timestamps less than -2**59 are not recommended.

- Some readers mishandle POSIX-style TZ strings that contain “<” or “>”. As a partial workaround, a writer can avoid using “<” or “>” for time zone abbreviations containing only alphabetic characters.

- Many readers mishandle time zone abbreviations that contain non-ASCII characters. These characters are not recommended.

- Some readers may mishandle time zone abbreviations that contain fewer than 3 or more than 6 characters, or that contain ASCII characters other than alphanumerics, “-”, and “+”. These abbreviations are not recommended.

- Some readers mishandle TZif files that specify daylight-saving time UT offsets that are less than the UT offsets for the corresponding standard time. These readers do not support locations like Ireland, which uses the equivalent of the POSIX TZ string “IST-1GMT0,M10.5.0,M3.5.0/1”, observing standard time (IST, +01) in summer and daylight saving time (GMT, +00) in winter. As a partial workaround, a writer can output data for the equivalent of the POSIX TZ string “GMT0IST,M3.5.0/1,M10.5.0”, thus swapping standard and daylight saving time. Although this workaround misidentifies which part of the year uses daylight saving time, it records UT offsets and time zone abbreviations correctly.

- Some readers generate ambiguous timestamps for positive leap seconds that occur when the UTC offset is not a multiple of 60 seconds. For example, in a timezone with UTC offset +01:23:45 and with a positive leap second 78796801 (1972-06-30 23:59:60 UTC), some readers will map both 78796800 and 78796801 to 01:23:45 local time the next day instead of mapping the latter to 01:23:46, and they will map 78796815 to 01:23:59 instead of to 01:23:60. This has not yet been a practical problem, since no civil authority has observed such UTC offsets since leap seconds were introduced in 1972.

Some interoperability problems are reader bugs that are listed here mostly as warnings to developers of readers.

- Some readers do not support negative timestamps. Developers of distributed applications should keep this in mind if they need to deal with pre-1970 data.

- Some readers mishandle timestamps before the first transition that has a nonnegative timestamp. Readers that do not support negative timestamps are likely to be more prone to this problem.

- Some readers mishandle time zone abbreviations like “-08” that contain “+”, “-”, or digits.

- Some readers mishandle UT offsets that are out of the traditional range of -12 through +12 hours, and so do not support locations like Kiritimati that are outside this range.

- Some readers mishandle UT offsets in the range [-3599, -1] seconds from UT, because they integer-divide the offset by 3600 to get 0 and then display the hour part as “+00”.

- Some readers mishandle UT offsets that are not a multiple of one hour, or of 15 minutes, or of 1 minute.

## SEE ALSO
time(2), localtime(3), tzset(3), tzselect(8), zdump(8), zic(8).

Olson A, Eggert P, Murchison K. The Time Zone Information Format (TZif). 2019 Feb. Internet RFC 8536 doi:10.17487/RFC8536.


utmp

title: utmp(5)

summary: login records

text:
# utmp(5)

## NAME
utmp, wtmp - login records

## SYNOPSIS

```
#include <utmp.h>
```

## DESCRIPTION
The utmp file allows one to discover information about who is currently using the system. There may be more users currently using the system, because not all programs use utmp logging.

Warning: utmp must not be writable by the user class "other", because many system programs (foolishly) depend on its integrity. You risk faked system logfiles and modifications of system files if you leave utmp writable to any user other than the owner and group owner of the file.

The file is a sequence of utmp structures, declared as follows in <utmp.h> (note that this is only one of several definitions around; details depend on the version of libc):

```
/* Values for ut_type field, below */
#define EMPTY         0 /* Record does not contain valid info

                           (formerly known as UT_UNKNOWN on Linux) */
#define RUN_LVL       1 /* Change in system run-level (see

                           init(1)) */
#define BOOT_TIME     2 /* Time of system boot (in ut_tv) */
#define NEW_TIME      3 /* Time after system clock change

                           (in ut_tv) */
#define OLD_TIME      4 /* Time before system clock change

                           (in ut_tv) */
#define INIT_PROCESS  5 /* Process spawned by init(1) */
#define LOGIN_PROCESS 6 /* Session leader process for user login */
#define USER_PROCESS  7 /* Normal process */
#define DEAD_PROCESS  8 /* Terminated process */
#define ACCOUNTING    9 /* Not implemented */
#define UT_LINESIZE      32
#define UT_NAMESIZE      32
#define UT_HOSTSIZE     256
struct exit_status {              /* Type for ut_exit, below */

    short e_termination;          /* Process termination status */

    short e_exit;                 /* Process exit status */
};
struct utmp {

    short   ut_type;              /* Type of record */

    pid_t   ut_pid;               /* PID of login process */

    char    ut_line[UT_LINESIZE]; /* Device name of tty - "/dev/" */

    char    ut_id[4];             /* Terminal name suffix,

                                     or inittab(5) ID */

    char    ut_user[UT_NAMESIZE]; /* Username */

    char    ut_host[UT_HOSTSIZE]; /* Hostname for remote login, or

                                     kernel version for run-level

                                     messages */

    struct  exit_status ut_exit;  /* Exit status of a process

                                     marked as DEAD_PROCESS; not

                                     used by Linux init(1) */

    /* The ut_session and ut_tv fields must be the same size when

       compiled 32- and 64-bit.  This allows data files and shared

       memory to be shared between 32- and 64-bit applications. */
#if __WORDSIZE == 64 && defined __WORDSIZE_COMPAT32

    int32_t ut_session;           /* Session ID (getsid(2)),

                                     used for windowing */

    struct {

        int32_t tv_sec;           /* Seconds */

        int32_t tv_usec;          /* Microseconds */

    } ut_tv;                      /* Time entry was made */
#else

     long   ut_session;           /* Session ID */

     struct timeval ut_tv;        /* Time entry was made */
#endif

    int32_t ut_addr_v6[4];        /* Internet address of remote

                                     host; IPv4 address uses

                                     just ut_addr_v6[0] */

    char __unused[20];            /* Reserved for future use */
};
/* Backward compatibility hacks */
#define ut_name ut_user
#ifndef _NO_UT_TIME
#define ut_time ut_tv.tv_sec
#endif
#define ut_xtime ut_tv.tv_sec
#define ut_addr ut_addr_v6[0]
```

This structure gives the name of the special file associated with the user's terminal, the user's login name, and the time of login in the form of time(2). String fields are terminated by a null byte ('\0') if they are shorter than the size of the field.

The first entries ever created result from init(1) processing inittab(5). Before an entry is processed, though, init(1) cleans up utmp by setting ut_type to DEAD_PROCESS, clearing ut_user, ut_host, and ut_time with null bytes for each record which ut_type is not DEAD_PROCESS or RUN_LVL and where no process with PID ut_pid exists. If no empty record with the needed ut_id can be found, init(1) creates a new one. It sets ut_id from the inittab, ut_pid and ut_time to the current values, and ut_type to INIT_PROCESS.

mingetty(8) (or agetty(8)) locates the entry by the PID, changes ut_type to LOGIN_PROCESS, changes ut_time, sets ut_line, and waits for connection to be established. login(1), after a user has been authenticated, changes ut_type to USER_PROCESS, changes ut_time, and sets ut_host and ut_addr. Depending on mingetty(8) (or agetty(8)) and login(1), records may be located by ut_line instead of the preferable ut_pid.

When init(1) finds that a process has exited, it locates its utmp entry by ut_pid, sets ut_type to DEAD_PROCESS, and clears ut_user, ut_host, and ut_time with null bytes.

xterm(1) and other terminal emulators directly create a USER_PROCESS record and generate the ut_id by using the string that suffix part of the terminal name (the characters following /dev/[pt]ty). If they find a DEAD_PROCESS for this ID, they recycle it, otherwise they create a new entry. If they can, they will mark it as DEAD_PROCESS on exiting and it is advised that they null ut_line, ut_time, ut_user, and ut_host as well.

telnetd(8) sets up a LOGIN_PROCESS entry and leaves the rest to login(1) as usual. After the telnet session ends, telnetd(8) cleans up utmp in the described way.

The wtmp file records all logins and logouts. Its format is exactly like utmp except that a null username indicates a logout on the associated terminal. Furthermore, the terminal name ~ with username shutdown or reboot indicates a system shutdown or reboot and the pair of terminal names |/} logs the old/new system time when date(1) changes it. wtmp is maintained by login(1), init(1), and some versions of getty(8) (e.g., mingetty(8) or agetty(8)). None of these programs creates the file, so if it is removed, record-keeping is turned off.

## FILES
/var/run/utmp

/var/log/wtmp

## VERSIONS
POSIX.1 does not specify a utmp structure, but rather one named utmpx (as part of the XSI extension), with specifications for the fields ut_type, ut_pid, ut_line, ut_id, ut_user, and ut_tv. POSIX.1 does not specify the lengths of the ut_line and ut_user fields.

Linux defines the utmpx structure to be the same as the utmp structure.

## STANDARDS
Linux.

## HISTORY
Linux utmp entries conform neither to v7/BSD nor to System V; they are a mix of the two.

v7/BSD has fewer fields; most importantly it lacks ut_type, which causes native v7/BSD-like programs to display (for example) dead or login entries. Further, there is no configuration file which allocates slots to sessions. BSD does so because it lacks ut_id fields.

In Linux (as in System V), the ut_id field of a record will never change once it has been set, which reserves that slot without needing a configuration file. Clearing ut_id may result in race conditions leading to corrupted utmp entries and potential security holes. Clearing the abovementioned fields by filling them with null bytes is not required by System V semantics, but makes it possible to run many programs which assume BSD semantics and which do not modify utmp. Linux uses the BSD conventions for line contents, as documented above.

System V has no ut_host or ut_addr_v6 fields.

## NOTES
Unlike various other systems, where utmp logging can be disabled by removing the file, utmp must always exist on Linux. If you want to disable who(1), then do not make utmp world readable.

The file format is machine-dependent, so it is recommended that it be processed only on the machine architecture where it was created.

Note that on biarch platforms, that is, systems which can run both 32-bit and 64-bit applications (x86-64, ppc64, s390x, etc.), ut_tv is the same size in 32-bit mode as in 64-bit mode. The same goes for ut_session and ut_time if they are present. This allows data files and shared memory to be shared between 32-bit and 64-bit applications. This is achieved by changing the type of ut_session to int32_t, and that of ut_tv to a struct with two int32_t fields tv_sec and tv_usec. Since ut_tv may not be the same as struct timeval, then instead of the call:

```
gettimeofday((struct timeval *) &ut.ut_tv, NULL);
```

the following method of setting this field is recommended:

```
struct utmp ut;
struct timeval tv;
gettimeofday(&tv, NULL);
ut.ut_tv.tv_sec = tv.tv_sec;
ut.ut_tv.tv_usec = tv.tv_usec;
```

## SEE ALSO
ac(1), date(1), init(1), last(1), login(1), logname(1), lslogins(1), users(1), utmpdump(1), who(1), getutent(3), getutmp(3), login(3), logout(3), logwtmp(3), updwtmp(3)


mandoc.conf

package: mandoc

title: mandoc.conf(5)

summary: configuration file for man

text:
# mandoc.conf(5)

## NAME
man.conf — configuration file for man

## DESCRIPTION
This is the configuration file for the man(1), apropos(1), and makewhatis(8) utilities. Its presence, and all directives, are optional.

This file is an ASCII text file. Leading whitespace on lines, lines starting with ‘#’, and blank lines are ignored. Words are separated by whitespace. The first word on each line is the name of a configuration directive.

The following directives are supported:

manpath path

Override the default search path for man(1), apropos(1), and makewhatis(8). It can be used multiple times to specify multiple paths, with the order determining the manual page search order. Each path is a tree containing subdirectories whose names consist of the strings ‘man’ and/or ‘cat’ followed by the names of sections, usually single digits. The former are supposed to contain unformatted manual pages in mdoc(7) and/or man(7) format; file names should end with the name of the section preceded by a dot. The latter should contain preformatted manual pages; file names should end with ‘.0’.

Creating a mandoc.db(5) database with makewhatis(8) in each directory configured with manpath is recommended and necessary for apropos(1) to work, and also for man(1) on operating systems like OpenBSD that install each manual page with only one file name in the file system, even if it documents multiple utilities or functions.

output option [value]

Configure the default value of an output option. These directives are overridden by the -O command line options of the same names. For details, see the mandoc(1) manual.

option

value

used by -T

purpose

fragment

none

html

print only body

includes

string

html

path to header files

indent

integer

ascii, utf8

left margin

man

string

html

path for Xr links

paper

string

ps, pdf

paper size

style

string

html

CSS file

toc

none

html

print table of contents

width

integer

ascii, utf8

right margin

## FILES
/etc/man.conf

## EXAMPLES
The following configuration file reproduces the defaults: installing it is equivalent to not having a man.conf file at all.

```
manpath /usr/share/man
manpath /usr/X11R6/man
manpath /usr/local/man
```

## SEE ALSO
apropos(1), man(1), makewhatis(8)

## HISTORY
A relatively complicated man.conf file format first appeared in 4.3BSD-Reno. For OpenBSD 5.8, it was redesigned from scratch, aiming for simplicity.

## AUTHORS
Ingo Schwarze <schwarze@openbsd.org>


mandoc.db

title: mandoc.db(5)

summary: manual page database

text:
# mandoc.db(5)

## NAME
mandoc.db — manual page database

## DESCRIPTION
The mandoc.db file format is used to store information about installed manual pages to facilitate semantic searching for manuals. Each manual page tree contains its own mandoc.db file; see FILES for examples.

Such database files are generated by makewhatis(8) and used by man(1), apropos(1) and whatis(1).

The file format uses three datatypes:

- 32-bit signed integer numbers in big endian (network) byte ordering

- NUL-terminated strings

- lists of NUL-terminated strings, terminated by a second NUL character

Numbers are aligned to four-byte boundaries; where they follow strings or lists of strings, padding with additional NUL characters occurs. Some, but not all, numbers point to positions in the file. These pointers are measured in bytes, and the first byte of the file is considered to be byte 0.

Each file consists of:

- One magic number, 0x3a7d0cdb.

- One version number, currently 1.

- One pointer to the macros table.

- One pointer to the final magic number.

- The pages table (variable length).

- The macros table (variable length).

- The magic number once again, 0x3a7d0cdb.

The pages table contains one entry for each physical manual page file, no matter how many hard and soft links it may have in the file system. The pages table consists of:

- The number of pages in the database.

- For each page:

- One pointer to the list of names.

- One pointer to the list of sections.

- One pointer to the list of architectures or 0 if the page is machine-independent.

- One pointer to the one-line description string.

- One pointer to the list of filenames.

- For each page, the list of names. Each name is preceded by a single byte indicating the sources of the name. The meaning of the bits is:

- 0x10: The name appears in a filename.

- 0x08: The name appears in a header line, i.e. in a .Dt or .TH macro.

- 0x04: The name is the first one in the title line, i.e. it appears in the first .Nm macro in the NAME section.

- 0x02: The name appears in any .Nm macro in the NAME section.

- 0x01: The name appears in an .Nm block in the SYNOPSIS section.

- For each page, the list of sections. Each section is given as a string, not as a number.

- For each architecture-dependent page, the list of architectures.

- For each page, the one-line description string taken from the .Nd macro.

- For each page, the list of filenames relative to the root of the respective manpath. This list includes hard links, soft links, and links simulated with .so roff(7) requests. The first filename is preceded by a single byte having the following significance:

- FORM_SRC = 0x01: The file format is mdoc(7) or man(7).

- FORM_CAT = 0x02: The manual page is preformatted.

- Zero to three NUL bytes for padding.

The macros table consists of:

- The number of different macro keys, currently 36. The ordering of macros is defined in <mansearch.h> and the significance of the macro keys is documented in apropos(1).

- For each macro key, one pointer to the respective macro table.

- For each macro key, the macro table (variable length).

Each macro table consists of:

- The number of entries in the table.

- For each entry:

- One pointer to the value of the macro key. Each value is a string of text taken from some macro invocation.

- One pointer to the list of pages.

- For each entry, the value of the macro key.

- Zero to three NUL bytes for padding.

- For each entry, one or more pointers to pages in the pages table, pointing to the pointer to the list of names, followed by the number 0.

## FILES
/usr/share/man/mandoc.db

The manual page database for the base system.

/usr/X11R6/man/mandoc.db

The same for the X(7) Window System.

/usr/local/man/mandoc.db

The same for packages(7).

A program to dump mandoc.db files in a human-readable format suitable for diff(1) is provided in the directory /usr/src/regress/usr.bin/mandoc/db/dbm_dump/.

## SEE ALSO
apropos(1), man(1), whatis(1), makewhatis(8)

## HISTORY
A manual page database /usr/lib/whatis first appeared in 2BSD. The present format first appeared in OpenBSD 6.1.

## AUTHORS
The original version of makewhatis(8) was written by Bill Joy in 1979. The present database format was designed by Ingo Schwarze <schwarze@openbsd.org> in 2016.


title: mapsoft2(5)

summary: tools for working with maps and geodata

text:
# mapsoft2(5)

## NAME
mapsoft2 -- tools for working with maps and geodata

## PROGRAMS

```
        ms2conv   -- converter for geodata
        ms2geofig -- Working with geo-referenced fig files
        ms2img    -- Convert raster images
        ms2mp     -- Convert MP vector maps
        ms2nom    -- Soviet nomenclature map calculations
        ms2proj   -- Convert coordinates
        ms2render -- Render geodata, srtm, raster and vector maps
        ms2tiles  -- TMS/Google tile calculations
        ms2view   -- Viewer for geodata and raster maps
        ms2vmap   -- Convert vector maps
        ms2vmapdb -- Working with vector map database
        ms2xyz    -- Writing track as a text table
```

## AUTHOR
Vladislav Zavjalov <slazav@altlinux.org>

## SEE ALSO

- Mapsoft2 documentation (ru, en) <http://slazav.github.io/mapsoft2>

- Mapsoft2 source code, bugtracker <http://github.com/slazav/mapsoft2>

- Old Mapsoft project <http://github.com/ushakov/mapsoft>