svcadm(8)을 검색하려면 섹션에서 8 을 선택하고, 맨 페이지 이름에 svcadm을 입력하고 검색을 누른다.
sysctl(9)
The kernel interface allows dynamic or static creation of MIB en‐
tries. All static sysctls are automatically destroyed when the
module which they are part of is unloaded. Most top level cate‐
gories are created statically and are available to all kernel
code and its modules. Pointer to sysctl context or NULL, if no
context. See for how to create a new sysctl context. Program‐
mers are strongly advised to use contexts to organize the dynamic
OIDs which they create because when a context is destroyed all
belonging sysctls are destroyed as well. This makes the sysctl
cleanup code much simpler. Else deletion of all created OIDs is
required at module unload. A pointer to a which is the head of
the parent's list of children. This pointer is retrieved using
the macro for static sysctls and the macro for dynamic sysctls.
The macro can be used to get the parent of an OID. The macro re‐
turns NULL if there is no parent. The OID number that will be
assigned to this OID. In almost all cases this should be set to
which will result in the assignment of the next available OID
number. The name of the OID. The newly created OID will contain
a copy of the name. A bit mask of sysctl control flags. See the
section below describing all the control flags. First callback
argument for procedure sysctls. Second callback argument for
procedure sysctls. The length of the data pointed to by the ar‐
gument. For string type OIDs a length of zero means that will be
used to get the length of the string at each access to the OID.
Pointer to sysctl variable or string data. For sysctl values the
pointer can be SYSCTL_NULL_XXX_PTR which means the OID is read-
only and the returned value should be taken from the argument.
If the argument is SYSCTL_NULL_XXX_PTR, gives the constant value
returned by this OID. Else this argument is not used. Name of
structure type. A pointer to the function that is responsible
for handling read and write requests to this OID. There are sev‐
eral standard handlers that support operations on nodes, inte‐
gers, strings and opaque objects. It is possible to define cus‐
tom handlers using the macro or the function. A pointer to a
string which specifies the format of the OID in a symbolic way.
This format is used as a hint by to apply proper data formatting
for display purposes. Current formats: node temperature in
Kelvin, multiplied by an optional single digit power of ten scal‐
ing factor: 1 (default) gives deciKelvin, 0 gives Kelvin, 3 gives
milliKelvin structures A pointer to a textual description of the
OID. A pointer to an aggregation label for this component of the
OID. To make it easier to export sysctl data to monitoring sys‐
tems that support aggregations through labels (e.g., Prometheus),
this argument can be used to attach a label name to an OID. The
label acts as a hint that this component's name should not be
part of the metric's name, but attached to the metric as a label
instead. Labels should only be applied to siblings that are
structurally similar and encode the same type of value, as aggre‐
gation is of no use otherwise. Sysctl MIBs or OIDs are created
in a hierarchical tree. The nodes at the bottom of the tree are
called root nodes, and have no parent OID. To create bottom tree
nodes the macro or the function needs to be used. By default all
static sysctl node OIDs are global and need a statement prior to
their definition statement, typically in a so-called header file.
Zero terminated character strings sysctls are created either us‐
ing the macro or the function. If the argument in zero, the
string length is computed at every access to the OID using The or
macros or the or functions create an OID that handle any chunk of
data of the size specified by the argument and data pointed to by
the argument. When using the structure version the type is en‐
coded as part of the created sysctl. The macro and the function
create OIDs with the specified function. The handler is respon‐
sible for handling all read and write requests to the OID. This
OID type is especially useful if the kernel data is not easily
accessible, or needs to be processed before exporting. Static
sysctls are declared using one of the or macros. Dynamic nodes
are created using one of the or functions. See or for more in‐
formation on how to destroy a dynamically created OID. For most
of the above functions and macros, declaring a type as part of
the access flags is not necessary — however, when declaring a
sysctl implemented by a function, including a type in the access
mask is required: This is a node intended to be a parent for
other nodes. This is a signed integer. This is a nul-terminated
string stored in a character array. This is an 8-bit signed in‐
teger. This is a 16-bit signed integer. This is a 32-bit signed
integer. This is a 64-bit signed integer. This is an opaque
data structure. Alias for This is an 8-bit unsigned integer.
This is a 16-bit unsigned integer. This is a 32-bit unsigned in‐
teger. This is a 64-bit unsigned integer. This is an unsigned
integer. This is a signed long. This is an unsigned long. All
sysctl types except for new node declarations require one of the
following flags to be set indicating the read and write disposi‐
tion of the sysctl: This is a read-only sysctl. This is a read-
only sysctl and tunable which is tried fetched once from the sys‐
tem environment early during module load or system boot. This is
a writable sysctl. This sysctl is readable and writable. This
is a readable and writeable sysctl and tunable which is tried
fetched once from the system environment early during module load
or system boot. In case the node is marked as a tunable using
the CTLFLAG_[XX]TUN, this flag will prevent fetching the initial
value from the system environment. Typically this flag should
only be used for very early low level system setup code, and not
by common drivers and modules. This handler is MP safe. Do not
grab Giant around calls to this handler. This should only be
used for entries. Additionally, any of the following optional
flags may also be specified: Any user or process can write to
this sysctl. A process in capability mode can read from this
sysctl. A process in capability mode can write to this sysctl.
This sysctl can be written to only if the effective securelevel
of the process is ≤ 0. This sysctl can be written to by
processes in When iterating the sysctl name space, do not list
this sysctl. Advisory flag that a system tunable also exists for
this variable. The initial sysctl value is tried fetched once
from the system environment early during module load or system
boot. Dynamically created OIDs automatically get this flag set.
OID references a VIMAGE-enabled variable. Sample use of to de‐
clare the sysctl tree for use by new nodes: SYSCTL_DECL(_secu‐
rity); Examples of integer, opaque, string, and procedure sysctls
follow: /*
* Example of a constant integer value. Notice that the control
* flags are CTLFLAG_RD, the variable pointer is
SYSCTL_NULL_INT_PTR,
* and the value is declared.
*/ SYSCTL_INT(_debug_sizeof, OID_AUTO, bio, CTLFLAG_RD,
SYSCTL_NULL_INT_PTR,
sizeof(struct bio), "sizeof(struct bio)");
/*
* Example of a variable integer value. Notice that the control
* flags are CTLFLAG_RW, the variable pointer is set, and the
* value is 0.
*/ static int doingcache = 1; /* 1 => enable the
cache */ SYSCTL_INT(_debug, OID_AUTO, vfscache, CTLFLAG_RW, &do‐
ingcache, 0,
"Enable name cache");
/*
* Example of a variable string value. Notice that the control
* flags are CTLFLAG_RW, that the variable pointer and string
* size are set. Unlike newer sysctls, this older sysctl uses a
* static oid number.
*/ char kernelname[MAXPATHLEN] = "/kernel"; /* XXX bloat
*/ SYSCTL_STRING(_kern, KERN_BOOTFILE, bootfile, CTLFLAG_RW,
kernelname, sizeof(kernelname), "Name of kernel file
booted");
/*
* Example of an opaque data type exported by sysctl. Notice
that
* the variable pointer and size are provided, as well as a for‐
mat
* string for sysctl(8).
*/ static l_fp pps_freq; /* scaled frequency offset (ns/s) */
SYSCTL_OPAQUE(_kern_ntp_pll, OID_AUTO, pps_freq, CTLFLAG_RD,
&pps_freq, sizeof(pps_freq), "I", "");
/*
* Example of a procedure based sysctl exporting string
* information. Notice that the data type is declared, the NULL
* variable pointer and 0 size, the function pointer, and the
* format string for sysctl(8).
*/ SYSCTL_PROC(_kern_timecounter, OID_AUTO, hardware, CTL‐
TYPE_STRING |
CTLFLAG_RW, NULL, 0, sysctl_kern_timecounter_hardware, "A",
""); The following is an example of how to create a new top-
level category and how to hook up another subtree to an existing
static node. This example does not use contexts, which results
in tedious management of all intermediate oids, as they need to
be freed later on: #include <sys/sysctl.h>
... /*
* Need to preserve pointers to newly created subtrees,
* to be able to free them later:
*/ static struct sysctl_oid *root1; static struct sysctl_oid
*root2; static struct sysctl_oid *oidp; static int a_int; static
char *string = "dynamic sysctl";
...
root1 = SYSCTL_ADD_ROOT_NODE(NULL, OID_AUTO, "newtree",
CTLFLAG_RW, 0, "new top level tree"); oidp = SYSCTL_ADD_INT(NULL,
SYSCTL_CHILDREN(root1), OID_AUTO, "newint", CTLFLAG_RW,
&a_int, 0, "new int leaf");
... root2 = SYSCTL_ADD_NODE(NULL, SYSCTL_STATIC_CHILDREN(_de‐
bug), OID_AUTO, "newtree", CTLFLAG_RW, 0, "new tree under
debug"); oidp = SYSCTL_ADD_STRING(NULL, SYSCTL_CHILDREN(root2),
OID_AUTO, "newstring", CTLFLAG_RD, string, 0, "new string
leaf"); This example creates the following subtrees: de‐
bug.newtree.newstring newtree.newint When adding, modifying, or
removing sysctl names, it is important to be aware that these in‐
terfaces may be used by users, libraries, applications, or docu‐
mentation (such as published books), and are implicitly published
application interfaces. As with other application interfaces,
caution must be taken not to break existing applications, and to
think about future use of new name spaces so as to avoid the need
to rename or remove interfaces that might be depended on in the
future. The semantics chosen for a new sysctl should be as clear
as possible, and the name of the sysctl must closely reflect its
semantics. Therefore the sysctl name deserves a fair amount of
consideration. It should be short but yet representative of the
sysctl meaning. If the name consists of several words, they
should be separated by underscore characters, as in Underscore
characters may be omitted only if the name consists of not more
than two words, each being not longer than four characters, as in
For boolean sysctls, negative logic should be totally avoided.
That is, do not use names like or They are confusing and lead to
configuration errors. Use positive logic instead: A temporary
sysctl node OID that should not be relied upon must be designated
as such by a leading underscore character in its name. For exam‐
ple: The utility first appeared in The implementation originally
found in has been extensively rewritten by in order to add sup‐
port for name lookups, name space iteration, and dynamic addition
of MIB nodes. This man page was written by When creating new
sysctls, careful attention should be paid to the security impli‐
cations of the monitoring or management interface being created.
Most sysctls present in the kernel are read-only or writable only
by the superuser. Sysctls exporting extensive information on
system data structures and operation, especially those imple‐
mented using procedures, will wish to implement access control to
limit the undesired exposure of information about other
processes, network connections, etc. The following top level
sysctl name spaces are commonly used: Compatibility layer infor‐
mation. Debugging information. Various name spaces exist under
Hardware and device driver information. Kernel behavior tuning;
generally deprecated in favor of more specific name spaces. Ma‐
chine-dependent configuration parameters. Network subsystem.
Various protocols have name spaces under Regression test configu‐
ration and information. Security and security-policy configura‐
tion and information. Reserved name space for the implementation
of sysctl. Configuration settings relating to user application
behavior. Generally, configuring applications using kernel
sysctls is discouraged. Virtual file system configuration and
information. Virtual memory subsystem configuration and informa‐
tion.