tripathysagar/man_text huggingface dataset:
# thread-keyring

## NAME



           thread-keyring - per-thread keyring
    


## DESCRIPTION



           The thread keyring is a keyring used to anchor keys on behalf of a
           process.  It is created only when a thread requests it.  The
           thread keyring has the name (description) __tid_.
    
           A special serial number value, **KEY_SPEC_THREAD_KEYRING** , is defined
           that can be used in lieu of the actual serial number of the
           calling thread's thread keyring.
    
           From the keyctl(1) utility, '**@t** ' can be used instead of a numeric
           key ID in much the same way, but as keyctl(1) is a program run
           after forking, this is of no utility.
    
           Thread keyrings are not inherited across clone(2) and fork(2) and
           are cleared by execve(2).  A thread keyring is destroyed when the
           thread that refers to it terminates.
    
           Initially, a thread does not have a thread keyring.  If a thread
           doesn't have a thread keyring when it is accessed, then it will be
           created if it is to be modified; otherwise the operation fails
           with the error **ENOKEY**.
    


* * *
# user-session-keyring

## NAME



           user-session-keyring - per-user default session keyring
    


## DESCRIPTION



           The user session keyring is a keyring used to anchor keys on
           behalf of a user.  Each UID the kernel deals with has its own user
           session keyring that is shared by all processes with that UID.
           The user session keyring has a name (description) of the form
           __uid_ses. <UID>_ where _< UID>_ is the user ID of the corresponding
           user.
    
           The user session keyring is associated with the record that the
           kernel maintains for the UID.  It comes into existence upon the
           first attempt to access either the user session keyring, the
           user-keyring(7), or the session-keyring(7).  The keyring remains
           pinned in existence so long as there are processes running with
           that real UID or files opened by those processes remain open.
           (The keyring can also be pinned indefinitely by linking it into
           another keyring.)
    
           The user session keyring is created on demand when a thread
           requests it or when a thread asks for its session-keyring(7) and
           that keyring doesn't exist.  In the latter case, a user session
           keyring will be created and, if the session keyring wasn't to be
           created, the user session keyring will be set as the process's
           actual session keyring.
    
           The user session keyring is searched by request_key(2) if the
           actual session keyring does not exist and is ignored otherwise.
    
           A special serial number value, **KEY_SPEC_USER_SESSION_KEYRING** , is
           defined that can be used in lieu of the actual serial number of
           the calling process's user session keyring.
    
           From the keyctl(1) utility, '**@us** ' can be used instead of a numeric
           key ID in much the same way.
    
           User session keyrings are independent of clone(2), fork(2),
           vfork(2), execve(2), and _exit(2) excepting that the keyring is
           destroyed when the UID record is destroyed when the last process
           pinning it exits.
    
           If a user session keyring does not exist when it is accessed, it
           will be created.
    
           Rather than relying on the user session keyring, it is strongly
           recommended—especially if the process is running as root—that a
           session-keyring(7) be set explicitly, for example by
           pam_keyinit(8).
    


## NOTES



           The user session keyring was added to support situations where a
           process doesn't have a session keyring, perhaps because it was
           created via a pathway that didn't involve PAM (e.g., perhaps it
           was a daemon started by **inetd**(8)).  In such a scenario, the user
           session keyring acts as a substitute for the session-keyring(7).
    


* * *
# complex

## NAME



           complex - basics of complex mathematics
    


## LIBRARY



           Math library (_libm_ , _-lm_)
    


## SYNOPSIS



           **#include <complex.h>**
    


## DESCRIPTION



           Complex numbers are numbers of the form z = a+b*i, where a and b
           are real numbers and i = sqrt(-1), so that i*i = -1.
    
           There are other ways to represent that number.  The pair (a,b) of
           real numbers may be viewed as a point in the plane, given by X-
           and Y-coordinates.  This same point may also be described by
           giving the pair of real numbers (r,phi), where r is the distance
           to the origin O, and phi the angle between the X-axis and the line
           Oz.  Now z = r*exp(i*phi) = r*(cos(phi)+i*sin(phi)).
    
           The basic operations are defined on z = a+b*i and w = c+d*i as:
    
           **addition: z+w = (a+c) + (b+d)*i**
    
           **multiplication: z*w = (a*c - b*d) + (a*d + b*c)*i**
    
           **division: z/w = ((a*c + b*d)/(c*c + d*d)) + ((b*c - a*d)/(c*c +**
           **d*d))*i**
    
           Nearly all math function have a complex counterpart but there are
           some complex-only functions.
    


## EXAMPLES



           Your C-compiler can work with complex numbers if it supports the
           C99 standard.  The imaginary unit is represented by I.
    
           /* check that exp(i * pi) == -1 */
           #include <math.h>        /* for atan */
           #include <stdio.h>
           #include <complex.h>
    
           int
           main(void)
           {
               double pi = 4 * atan(1.0);
               double complex z = cexp(I * pi);
               printf("%f + %f * i\n", creal(z), cimag(z));
           }
    


* * *
# pcap-linktype

## NAME



           pcap-linktype - link-layer header types supported by libpcap
    


## DESCRIPTION



           For a live capture or ``savefile'', libpcap supplies, as the
           return value of the **pcap_datalink**(3PCAP) routine, a value that
           indicates the type of link-layer header at the beginning of the
           packets it provides.  This is not necessarily the type of link-
           layer header that the packets being captured have on the network
           from which they're being captured; for example, packets from an
           IEEE 802.11 network might be provided by libpcap with Ethernet
           headers that the network adapter or the network adapter driver
           generates from the 802.11 headers.  The names for those values
           begin with **DLT_** , so they are sometimes called "DLT_ values".
    
           The **pcap_datalink_val_to_name**(3PCAP) and
           **pcap_datalink_name_to_val**(3PCAP) routines can be used to translate
           between **DLT_** values and names.  Some capture devices support more
           than one link-layer header type.  The **pcap_list_datalinks**(3PCAP)
           routine can be used to retrieve the supported link-layer header
           types of a capture device and the **pcap_set_datalink**(3PCAP) routine
           can be used to change the link-layer header type of a capture
           device.
    
           The values stored in the link-layer header type field in the
           savefile header are, in most but not all cases, the same as the
           values returned by **pcap_datalink**().  The names for those values
           begin with **LINKTYPE_**.
    
           The link-layer header types supported by libpcap are described at
           https://www.tcpdump.org/linktypes.html .
    


* * *
# babeltrace2-plugin-lttng-utils

## NAME



           babeltrace2-plugin-lttng-utils - Babeltrace 2: LTTng utilities
           plugin
    


## DESCRIPTION



           The Babeltrace 2 **lttng-utils** plugin contains utilities that apply
           to LTTng traces. You can use the **source.ctf.fs** and
           **source.ctf.lttng-live** components to read LTTng traces (see
           babeltrace2-plugin-ctf(7)).
    
           See babeltrace2-intro(7) to learn more about the Babeltrace 2
           project and its core concepts.
    


## COMPONENT CLASSES



           **filter.lttng-utils.debug-info**
               Adds debugging information to compatible LTTng event messages.
    
               See babeltrace2-filter.lttng-utils.debug-info(7).
    


## BUGS



           If you encounter any issue or usability problem, please report it
           on the Babeltrace bug tracker (see
           <https://bugs.lttng.org/projects/babeltrace>).
    


## RESOURCES



           The Babeltrace project shares some communication channels with the
           LTTng project (see <https://lttng.org/>).
    
           •   Babeltrace website (see <https://babeltrace.org/>)
    
           •   Mailing list (see <https://lists.lttng.org>) for support and
               development: **lttng-dev@lists.lttng.org**
    
           •   IRC channel (see <irc://irc.oftc.net/lttng>): **#lttng** on
               **irc.oftc.net**
    
           •   Bug tracker (see <https://bugs.lttng.org/projects/babeltrace>)
    
           •   Git repository (see
               <https://git.efficios.com/?p=babeltrace.git>)
    
           •   GitHub project (see <https://github.com/efficios/babeltrace>)
    
           •   Continuous integration (see
               <https://ci.lttng.org/view/Babeltrace/>)
    
           •   Code review (see
               <https://review.lttng.org/q/project:babeltrace>)
    


* * *
# dpkg-build-api

## NAME



           dpkg-build-api - source package dpkg build API level
    


## SYNOPSIS



            Build-Depends:
             dpkg-build-api (= 1),
    


## DESCRIPTION



           The source package dpkg build API level, defines a versioned
           interface for source packages, where each API level provides
           specific behaviors and guarantees.
    
           These interfaces can then be adopted by packages in a gradual way,
           and phased out more easily than with global behavior changes.
    
           The declaration of this API level is done through
           build-dependencies, in one of **Build-Depends** , **Build-Depends-Indep**
           or **Build-Depends-Arch** , or via the environment variable
           **DPKG_BUILD_API** , which will override these if both are present, and
           might emit a warning in case they are different.
    


## API LEVELS



           v2  This level is still under development, and cannot be declared
               via build-dependencies.
    
           v1  This is the recommended level.  Since dpkg 1.22.0.
    
               Changes from v0 are:
    
               •   **dpkg-shlibdeps** no longer uses the **LD_LIBRARY_PATH**
                   environment variable.  The **-l** option should be used
                   instead.
    
               •   **dpkg-buildpackage** defaults to **Rules-Requires-Root** value
                   **no**.  To restore the **v0** behavior (from before dpkg 1.22.13)
                   **Rules-Requires-Root** should be set to **binary-targets**.
    
               •   **dpkg-buildpackage** expects all required _debian/rules_
                   targets to be supported and no longer has backwards
                   compatibility fallback code.  The required targets are
                   **clean** , **build** , **build-indep** , **build-arch** , **binary-indep** and
                   **binary-arch**.
    
               •   **vendor.mk** defaults to using **dpkg_vendor_derives_from_v1**
                   for the **dpkg_vendor_derives_from** macro.  To restore the **v0**
                   behavior set **dpkg_vendor_derives_from** to
                   **dpkg_vendor_derives_from_v0**.
    
               •   **default.mk** defaults to including **buildtools.mk**.
    
           v0  This is the current global level, equivalent to not specifying
               one.  The interfaces and behaviors provided are subject to the
               normal global interface updates, which tend to require longer
               deprecation cycles and/or coordinated transitions.
    


* * *
# session-keyring

## NAME



           session-keyring - session shared process keyring
    


## DESCRIPTION



           The session keyring is a keyring used to anchor keys on behalf of
           a process.  It is typically created by pam_keyinit(8) when a user
           logs in and a link will be added that refers to the
           user-keyring(7).  Optionally, **PAM**(7) may revoke the session
           keyring on logout.  (In typical configurations, PAM does do this
           revocation.)  The session keyring has the name (description) __ses_.
    
           A special serial number value, **KEY_SPEC_SESSION_KEYRING** , is
           defined that can be used in lieu of the actual serial number of
           the calling process's session keyring.
    
           From the keyctl(1) utility, '**@s** ' can be used instead of a numeric
           key ID in much the same way.
    
           A process's session keyring is inherited across clone(2), fork(2),
           and vfork(2).  The session keyring is preserved across execve(2),
           even when the executable is set-user-ID or set-group-ID or has
           capabilities.  The session keyring is destroyed when the last
           process that refers to it exits.
    
           If a process doesn't have a session keyring when it is accessed,
           then, under certain circumstances, the user-session-keyring(7)
           will be attached as the session keyring and under others a new
           session keyring will be created.  (See user-session-keyring(7) for
           further details.)
    
       **Special operations**
           The _keyutils_ library provides the following special operations for
           manipulating session keyrings:
    
           keyctl_join_session_keyring(3)
                  This operation allows the caller to change the session
                  keyring that it subscribes to.  The caller can join an
                  existing keyring with a specified name (description),
                  create a new keyring with a given name, or ask the kernel
                  to create a new "anonymous" session keyring with the name
                  "_ses".  (This function is an interface to the keyctl(2)
                  **KEYCTL_JOIN_SESSION_KEYRING** operation.)
    
           keyctl_session_to_parent(3)
                  This operation allows the caller to make the parent
                  process's session keyring to the same as its own.  For this
                  to succeed, the parent process must have identical security
                  attributes and must be single threaded.  (This function is
                  an interface to the keyctl(2) **KEYCTL_SESSION_TO_PARENT**
                  operation.)
    
           These operations are also exposed through the keyctl(1) utility
           as:
    
               keyctl session
               keyctl session - [<prog> <arg1> <arg2> ...]
               keyctl session <name> [<prog> <arg1> <arg2> ...]
    
           and:
    
               keyctl new_session
    


* * *
# keyutils

## NAME



           keyutils - in-kernel key management utilities
    


## DESCRIPTION



           The **keyutils** package is a library and a set of utilities for
           accessing the kernel **keyrings** facility.
    
           A header file is supplied to provide the definitions and
           declarations required to access the library:
    
                  **#include <keyutils.h>**
    
           To link with the library, the following:
    
                  **-lkeyutils**
    
           should be specified to the linker.
    
           Three system calls are provided:
    
           add_key(2)
                  Supply a new key to the kernel.
    
           request_key(2)
                  Find an existing key for use, or, optionally, create one if
                  one does not exist.
    
           keyctl(2)
                  Control a key in various ways.  The library provides a
                  variety of wrappers around this system call and those
                  should be used rather than calling it directly.
    
           See the add_key(2), request_key(2), and keyctl(2) manual pages for
           more information.
    
           The **keyctl**() wrappers are listed on the keyctl(3) manual page.
    


## UTILITIES



           A program is provided to interact with the kernel facility by a
           number of subcommands, e.g.:
    
                  **keyctl add user foo bar @s**
    
           See the keyctl(1) manual page for information on that.
    
           The kernel has the ability to upcall to userspace to fabricate new
           keys.  This can be triggered by **request_key**(), but userspace is
           better off using **add_key**() instead if it possibly can.
    
           The upcalling mechanism is usually routed via the request-key(8)
           program.  What this does with any particular key is configurable
           in:
    
                  _/etc/request-key.conf_
                  _/etc/request-key.d/_
    
           See the request-key.conf(5) and the request-key(8) manual pages
           for more information.
    


* * *
# groff_mmse

## Namn



           groff_mmse - svenska ”memorandum” makro för GNU _roff_
    


## Syntax



           **groff -mmse**[_flaggor_ ...] [_filer_ ...]
    
           **groff -m mmse**[_flaggor_ ...] [_filer_ ...]
    


## Beskrivning



           _mmse_ är en svensk variant av _mm_.  Alla texter är översatta.  En A4
           sida får text som är 13 cm bred, 3,5 cm indragning samt är 28,5 cm
           hög.  Det finns stöd för brevuppställning enligt svensk standard
           för vänster och högerjusterad text.
    
           **COVER** kan använda _se_ms_ som argument.  Detta ger ett svenskt
           försättsblad.  Se _groff_mm_(7) för övriga detaljer.
    


## Brev



           Tillgängliga brevtyper:
    
           **.LT SVV**
                  Vänsterställd löptext med adressat i position T0
                  (vänsterställt).
    
           **.LT SVH**
                  Högerställd löptext med adressat i position T4 (passar
                  fönsterkuvert).
    
           Följande extra LO-variabler används.
    
           **.LO DNAMN** _namn_
                  Anger dokumentets namn.
    
           **.LO MDAT** _datum_
                  Mottagarens datum, anges under **Ert datum:**(**LetMDAT**).
    
           **.LO BIL** _sträng_
                  Anger bilaga, nummer eller sträng med **Bilaga**(**LetBIL**) som
                  prefix.
    
           **.LO KOMP** _text_
                  Anger kompletteringsuppgift.
    
           **.LO DBET** _beteckning_
                  Anger dokumentbeteckning eller dokumentnummer.
    
           **.LO BET** _beteckning_
                  Anger beteckning (ärendebeteckning i form av diarienummer
                  eller liknande).
    
           **.LO SIDOR** _antal_
                  Anger totala antalet sidor och skrivs ut efter sidnumret
                  inom parenteser.
    
           Om makrot **.TP** är definierat anropas det efter utskrift av
           brevhuvudet.  Där lägger man lämpligen in postadress och annat som
           brevfot.
    


## Skrivet av



           Jörgen Hägg ⟨Jorgen.Hagg@axis.se⟩, Lund, Sweden
    


## Filer



           _/usr/local/share/groff/1.23.0/tmac/mse.tmac_
    
           _/usr/local/share/groff/1.23.0/tmac/mm/se__ *_.cov_
    


## Se också



           _groff_mm_(7)
    


* * *
# fifo

## NAME



           fifo - first-in first-out special file, named pipe
    


## DESCRIPTION



           A FIFO special file (a named pipe) is similar to a pipe, except
           that it is accessed as part of the filesystem.  It can be opened
           by multiple processes for reading or writing.  When processes are
           exchanging data via the FIFO, the kernel passes all data
           internally without writing it to the filesystem.  Thus, the FIFO
           special file has no contents on the filesystem; the filesystem
           entry merely serves as a reference point so that processes can
           access the pipe using a name in the filesystem.
    
           The kernel maintains exactly one pipe object for each FIFO special
           file that is opened by at least one process.  The FIFO must be
           opened on both ends (reading and writing) before data can be
           passed.  Normally, opening the FIFO blocks until the other end is
           opened also.
    
           A process can open a FIFO in nonblocking mode.  In this case,
           opening for read-only succeeds even if no one has opened on the
           write side yet and opening for write-only fails with **ENXIO**(no
           such device or address) unless the other end has already been
           opened.
    
           Under Linux, opening a FIFO for read and write will succeed both
           in blocking and nonblocking mode.  POSIX leaves this behavior
           undefined.  This can be used to open a FIFO for writing while
           there are no readers available.  A process that uses both ends of
           the connection in order to communicate with itself should be very
           careful to avoid deadlocks.
    


## NOTES



           For details of the semantics of I/O on FIFOs, see pipe(7).
    
           When a process tries to write to a FIFO that is not opened for
           read on the other side, the process is sent a **SIGPIPE** signal.
    
           FIFO special files can be created by mkfifo(3), and are indicated
           by _ls -l_ with the file type 'p'.
    


* * *
# error::pass4

## NAME



           error::pass4 - systemtap pass-4 errors
    


## DESCRIPTION



           Errors that occur during pass 4 (compilation) have generally only
           a few causes:
    
           kernel or OS version changes
                  The systemtap runtime and embedded-C fragments in the
                  tapset library are designed to be portable across a wide
                  range of OS versions.  However, incompatibilities can occur
                  when some OS changes occur, such as kernel modifications
                  that change functions, types, or macros referenced by
                  systemtap.  Upstream
                  (git://sourceware.org/git/systemtap.git) builds of
                  systemtap are often quickly updated to include relevant
                  fixes, so try getting or making an updated build.
                  Reworded: **build systemtap from git for use with very young**
                  **kernels**.  If the issue persists, report the problem to the
                  systemtap developers.
    
           buggy embedded-C code
                  Embedded-C code in your own guru-mode script cannot be
                  checked by systemtap, and is passed through verbatim to the
                  compiler.  Errors in such snippets of code may be found
                  during the pass-4 compiler invocation, though may be hard
                  to identify by the compiler errors.
    
           incompatible embedded-C code
                  The interface standards between systemtap-generated code
                  and embedded-C code occasionally change.  For example,
                  before version 1.8, arguments were passed using macros
                  _THIS- >foo_ and _THIS- >__retvalue_ but from version 1.8 onward,
                  using _STAP_ARG_foo_ and _STAP_RETVALUE_.  Adjust your
                  embedded-C code to current standards, or use the _stap_
                  _--compatible=VERSION_ option to make systemtap use a
                  different one.
    
           compiler bugs and mysteries
                  Messages such as "internal compiler error" suggest compiler
                  problems.  These should be reported to the compiler
                  developers in the form of a preprocessed _.i_ file, plus the
                  compiler command line.  To gather relevant information, run
    
                  stap -k --vp 0003 -p4 ....
    
                  Systemtap will report the saved temporary directory, and
                  the compiler command line it attempted.  Go to the directo‐
                  ry to find he main generated file _stap_NNNNN_src.c_.  Force
                  the compiler to produce a preprocessed file with:
    
                  make -C /lib/modules/`uname -r`/build M=`pwd` stap_NNNNN_src.i
    
                  (note the _.i_ suffix), and the compiler command line should
                  be in the file _.stap_NNNNN_src.i.cmd_.
    


* * *
# process-keyring

## NAME



           process-keyring - per-process shared keyring
    


## DESCRIPTION



           The process keyring is a keyring used to anchor keys on behalf of
           a process.  It is created only when a process requests it.  The
           process keyring has the name (description) __pid_.
    
           A special serial number value, **KEY_SPEC_PROCESS_KEYRING** , is
           defined that can be used in lieu of the actual serial number of
           the calling process's process keyring.
    
           From the keyctl(1) utility, '**@p** ' can be used instead of a numeric
           key ID in much the same way, but since keyctl(1) is a program run
           after forking, this is of no utility.
    
           A thread created using the clone(2) **CLONE_THREAD** flag has the same
           process keyring as the caller of clone(2).  When a new process is
           created using **fork**() it initially has no process keyring.  A
           process's process keyring is cleared on execve(2).  The process
           keyring is destroyed when the last thread that refers to it
           terminates.
    
           If a process doesn't have a process keyring when it is accessed,
           then the process keyring will be created if the keyring is to be
           modified; otherwise, the error **ENOKEY** results.
    


* * *
# babeltrace2-plugin-ctf

## NAME



           babeltrace2-plugin-ctf - Babeltrace 2: CTF plugin
    


## DESCRIPTION



           The Babeltrace 2 **ctf** plugin contains component classes to read and
           write traces following the Common Trace Format (see
           <https://diamon.org/ctf/>).
    
           See babeltrace2-intro(7) to learn more about the Babeltrace 2
           project and its core concepts.
    


## COMPONENT CLASSES



           **source.ctf.fs**
               Opens a CTF trace on the file system and emits the messages of
               its data stream files.
    
               See babeltrace2-source.ctf.fs(7).
    
           **source.ctf.lttng-live**
               Connects to an LTTng (see <https://lttng.org/>) relay daemon
               and emits the messages of the received CTF data streams.
    
               See babeltrace2-source.ctf.lttng-live(7).
    
           **sink.ctf.fs**
               Writes the consumed messages as one or more CTF traces on the
               file system.
    
               See babeltrace2-sink.ctf.fs(7).
    


## BUGS



           If you encounter any issue or usability problem, please report it
           on the Babeltrace bug tracker (see
           <https://bugs.lttng.org/projects/babeltrace>).
    


## RESOURCES



           The Babeltrace project shares some communication channels with the
           LTTng project (see <https://lttng.org/>).
    
           •   Babeltrace website (see <https://babeltrace.org/>)
    
           •   Mailing list (see <https://lists.lttng.org>) for support and
               development: **lttng-dev@lists.lttng.org**
    
           •   IRC channel (see <irc://irc.oftc.net/lttng>): **#lttng** on
               **irc.oftc.net**
    
           •   Bug tracker (see <https://bugs.lttng.org/projects/babeltrace>)
    
           •   Git repository (see
               <https://git.efficios.com/?p=babeltrace.git>)
    
           •   GitHub project (see <https://github.com/efficios/babeltrace>)
    
           •   Continuous integration (see
               <https://ci.lttng.org/view/Babeltrace/>)
    
           •   Code review (see
               <https://review.lttng.org/q/project:babeltrace>)
    


* * *
# ibacm

## NAME



           ibacm - InfiniBand communication management assistant
    


## SYNOPSIS



           **#include <infiniband/acm.h>**
    


## DESCRIPTION



           Used to resolve remote endpoint information before establishing
           communications over InfiniBand.
    


## NOTES



           Th IB ACM provides scalable address and route resolution services
           over InfiniBand.  It resolves system network names and IP
           addresses to InfiniBand path record data using efficient
           mechanisms, including caching of data.
    
           The IB ACM provides information needed to establish a connection,
           but does not implement the communication management protocol.  It
           provides services similar to rdma_getaddrinfo, rdma_resolve_addr,
           and rdma_resolve_route using IB multicast.  The IB ACM does not
           require IPoIB or use standard naming services, such as DNS, and
           limits network communication, especially with the IB SA.  The
           ib_acme utility assists in verifying what options of the ibacm
           service may be usable for the current fabric topology.
    
           Client interactions with the ibacm service are done over sockets
           through a standard TCP connection.  The librdmacm abstracts this
           interaction.
    


## RETURN CODES



           == 0   success
    
           != 0   error
    


* * *
# warning::pass5

## NAME



           warning::pass5 - systemtap pass-5 warnings
    


## DESCRIPTION



           Warnings that occur during pass 5 (execution) can have a variety
           of causes.
    
           probe insertion errors
                  With any of the systemtap runtimes, it may be possible that
                  the backends are unable to insert probe points requested by
                  the systemtap script.  For example, you may see errors such
                  as
    
                  WARNING: probe [...] registration error (rc -524)
    
                  (524 is a kernel error code for ENOTSUPP).  These situa‐
                  tions are out of systemtap's control, and result in some
                  probes not receiving any hits.  This may be caused by tem‐
                  porary resource constraints or permanent problems.  One
                  common permanent problem is such a probe point being placed
                  at instructions that the runtime (kernel kprobes, uprobes
                  or dyninst) cannot decode or intercept.  A possible
                  workaround is to move the probe points slightly in the
                  script, so as to target a nearby statement, or a caller, or
                  a callee.  See also error::dwarf(7stap).
    


## GATHERING MORE INFORMATION



           Increasing the verbosity of pass-5 with an option such as _--vp_
           _00001_ can help pinpoint the problem.
    


* * *
# smbios-type-11

## NAME



           smbios-type-11 - SMBIOS Type 11 strings
    


## SYNOPSIS



           /sys/firmware/dmi/entries/11-*/raw
    


## DESCRIPTION



           Various OS components process SMBIOS Type 11 vendor strings that a
           virtual machine manager (VMM) may set and a virtual machine (VM)
           receives. SMBIOS Type 11 vendor strings may play a similar role as
           kernel-command-line(7) parameters but generally are under control
           of the VMM rather than the boot loader or UKI.
    
           For details on SMBIOS Type 11 see the **System Management BIOS******[1]
           specifications.


## STRINGS



           The following strings are supported:
    
           _io.systemd.credential:CREDENTIAL=VALUE_ ,
           _io.systemd.credential.binary:CREDENTIAL=VALUE_
               This allows passing additional system credentials into the
               system, in textual or binary (Base64) form. See
               systemd.exec(5) and **System and Service Credentials******[2] for
               details.
    
               Added in version 252._io.systemd.stub.kernel-cmdline-extra=CMDLINE_
               This allows configuration of additional kernel command line
               options, and is read by the kernel UEFI stub. For details see
               systemd-stub(7).
    
               Added in version 254.
    
           _io.systemd.boot.kernel-cmdline-extra=CMDLINE_
               This allows configuration of additional kernel command line
               options for Boot Loader Specification Type 1 entries, and is
               read by **systemd-boot**. For details see systemd-boot(7).
    
               Added in version 256.
    
           _io.systemd.boot-entries.extra:ID=DEFINITION_
               This allows inserting additional entries into the **systemd-boot**
               menu. For details see systemd-boot(7)
    
               Added in version 258.
    


## NOTES



            1. System Management BIOS
               https://www.dmtf.org/standards/smbios/
    
            2. System and Service Credentials
               https://systemd.io/CREDENTIALS
    


* * *
# babeltrace2-sink.utils.dummy

## NAME



           babeltrace2-sink.utils.dummy - Babeltrace 2: Dummy sink component
           class
    


## DESCRIPTION



           A Babeltrace 2 **sink.utils.dummy** component consumes messages and
           discards them (does absolutely nothing with them).
    
                           +------------------+
                           | sink.utils.dummy |
                           |                  |
               Messages -->@ in               |
                           +------------------+
    
           See babeltrace2-intro(7) to learn more about the Babeltrace 2
           project and its core concepts.
    
           A **sink.utils.dummy** sink component can be useful to run a trace
           processing graph with no sink side effect, for example to perform
           benchmarks. Prefer a **sink.utils.dummy** component class for such
           tasks to, for example, a **sink.text.pretty** component and sending
           its output to **/dev/null** , as a **sink.text.pretty** component still
           performs formatting operations.
    


## PORTS



               +------------------+
               | sink.utils.dummy |
               |                  |
               @ in               |
               +------------------+
    
       **Input**
           **in**
               Single input port.
    


## BUGS



           If you encounter any issue or usability problem, please report it
           on the Babeltrace bug tracker (see
           <https://bugs.lttng.org/projects/babeltrace>).
    


## RESOURCES



           The Babeltrace project shares some communication channels with the
           LTTng project (see <https://lttng.org/>).
    
           •   Babeltrace website (see <https://babeltrace.org/>)
    
           •   Mailing list (see <https://lists.lttng.org>) for support and
               development: **lttng-dev@lists.lttng.org**
    
           •   IRC channel (see <irc://irc.oftc.net/lttng>): **#lttng** on
               **irc.oftc.net**
    
           •   Bug tracker (see <https://bugs.lttng.org/projects/babeltrace>)
    
           •   Git repository (see
               <https://git.efficios.com/?p=babeltrace.git>)
    
           •   GitHub project (see <https://github.com/efficios/babeltrace>)
    
           •   Continuous integration (see
               <https://ci.lttng.org/view/Babeltrace/>)
    
           •   Code review (see
               <https://review.lttng.org/q/project:babeltrace>)
    


* * *
# hostname

## NAME



           hostname - hostname resolution description
    


## DESCRIPTION



           Hostnames are domains, where a domain is a hierarchical, dot-
           separated list of subdomains; for example, the machine "monet", in
           the "example" subdomain of the "com" domain would be represented
           as "monet.example.com".
    
           Each element of the hostname must be from 1 to 63 characters long
           and the entire hostname, including the dots, can be at most 253
           characters long.  Valid characters for hostnames are ASCII(7)
           letters from _a_ to _z_ , the digits from _0_ to _9_ , and the hyphen (-).
           A hostname may not start with a hyphen.
    
           Hostnames are often used with network client and server programs,
           which must generally translate the name to an address for use.
           (This task is generally performed by either getaddrinfo(3) or the
           obsolete gethostbyname(3).)
    
           Hostnames are resolved by the NSS framework in glibc according to
           the **hosts** configuration in nsswitch.conf(5).  The DNS-based name
           resolver (in the **dns** NSS service module) resolves them in the
           following fashion.
    
           If the name consists of a single component, that is, contains no
           dot, and if the environment variable **HOSTALIASES** is set to the
           name of a file, that file is searched for any string matching the
           input hostname.  The file should consist of lines made up of two
           white-space separated strings, the first of which is the hostname
           alias, and the second of which is the complete hostname to be
           substituted for that alias.  If a case-insensitive match is found
           between the hostname to be resolved and the first field of a line
           in the file, the substituted name is looked up with no further
           processing.
    
           If the input name ends with a trailing dot, the trailing dot is
           removed, and the remaining name is looked up with no further
           processing.
    
           If the input name does not end with a trailing dot, it is looked
           up by searching through a list of domains until a match is found.
           The default search list includes first the local domain, then its
           parent domains with at least 2 name components (longest first).
           For example, in the domain cs.example.com, the name lithium.cchem
           will be checked first as lithium.cchem.cs.example and then as
           lithium.cchem.example.com.  lithium.cchem.com will not be tried,
           as there is only one component remaining from the local domain.
           The search path can be changed from the default by a system-wide
           configuration file (see resolver(5)).
    


* * *
# intro

## NAME



           intro - introduction to games
    


## DESCRIPTION



           Section 6 of the manual describes the games and funny little
           programs available on the system.
    


## NOTES



       **Authors and copyright conditions**
           Look at the header of the manual page source for the author(s) and
           copyright conditions.  Note that these can be different from page
           to page!
    


* * *
# seq

## NAME



           seq - print a sequence of numbers
    


## SYNOPSIS



           **seq**[_OPTION_]... _LAST_
           **seq**[_OPTION_]... _FIRST LAST_
           **seq**[_OPTION_]... _FIRST INCREMENT LAST_
    


## DESCRIPTION



           Print numbers from FIRST to LAST, in steps of INCREMENT.
    
           Mandatory arguments to long options are mandatory for short
           options too.
    
           **-f** , **--format** =_FORMAT_
                  use printf style floating-point FORMAT
    
           **-s** , **--separator** =_STRING_
                  use STRING to separate numbers (default: \n)
    
           **-w** , **--equal-width**
                  equalize width by padding with leading zeroes
    
           **--help** display this help and exit
    
           **--version**
                  output version information and exit
    
           If FIRST or INCREMENT is omitted, it defaults to 1.  That is, an
           omitted INCREMENT defaults to 1 even when LAST is smaller than
           FIRST.  The sequence of numbers ends when the sum of the current
           number and INCREMENT would become greater than LAST.  FIRST,
           INCREMENT, and LAST are interpreted as floating point values.
           INCREMENT is usually positive if FIRST is smaller than LAST, and
           INCREMENT is usually negative if FIRST is greater than LAST.
           INCREMENT must not be 0; none of FIRST, INCREMENT and LAST may be
           NaN.  FORMAT must be suitable for printing one argument of type
           'double'; it defaults to %.PRECf if FIRST, INCREMENT, and LAST are
           all fixed point decimal numbers with maximum precision PREC, and
           to %g otherwise.
    


* * *
# git-request-pull

## NAME



           git-request-pull - Generates a summary of pending changes
    


## SYNOPSIS



           _git request-pull_ [-p] <start> <URL> [<end>]
    


## DESCRIPTION



           Generate a request asking your upstream project to pull changes
           into their tree. The request, printed to the standard output,
           begins with the branch description, summarizes the changes, and
           indicates from where they can be pulled.
    
           The upstream project is expected to have the commit named by
           _< start>_ and the output asks it to integrate the changes you made
           since that commit, up to the commit named by _< end>_, by visiting
           the repository named by _< URL>_.
    


## OPTIONS



           -p
               Include patch text in the output.
    
           <start>
               Commit to start at. This names a commit that is already in the
               upstream history.
    
           <URL>
               The repository URL to be pulled from.
    
           <end>
               Commit to end at (defaults to HEAD). This names the commit at
               the tip of the history you are asking to be pulled.
    
               When the repository named by _< URL>_ has the commit at a tip of
               a ref that is different from the ref you have locally, you can
               use the _< local>_**:**_< remote>_ syntax, to have its local name, a
               colon **:** , and its remote name.
    


## EXAMPLES



           Imagine that you built your work on your **master** branch on top of
           the **v1.0** release, and want it to be integrated into the project.
           First you push that change to your public repository for others to
           see:
    
               git push https://git.ko.xz/project master
    
           Then, you run this command:
    
               git request-pull v1.0 https://git.ko.xz/project master
    
           which will produce a request to the upstream, summarizing the
           changes between the **v1.0** release and your **master** , to pull it from
           your public repository.
    
           If you pushed your change to a branch whose name is different from
           the one you have locally, e.g.
    
               git push https://git.ko.xz/project master:for-linus
    
           then you can ask that to be pulled with
    
               git request-pull v1.0 https://git.ko.xz/project master:for-linus
    


## GIT



           Part of the git(1) suite
    


* * *
# systemd-tty-ask-password-agent

## NAME



           systemd-tty-ask-password-agent - List or process pending systemd
           password requests
    


## SYNOPSIS



    
           **systemd-tty-ask-password-agent**[OPTIONS...] [VARIABLE=VALUE...]
    


## DESCRIPTION



           **systemd-tty-ask-password-agent** is a password agent that handles
           password requests of the system, for example for hard disk
           encryption passwords or SSL certificate passwords that need to be
           queried at boot-time or during runtime.
    
           **systemd-tty-ask-password-agent** implements the **Password Agents**
           **Specification******[1], and is one of many possible response agents
           which answer to queries formulated withsystemd-ask-password(1).
    


## OPTIONS



           The following options are understood:
    
           **--list**
               Lists all currently pending system password requests.
    
               Added in version 186.
    
           **--query**
               Process all currently pending system password requests by
               querying the user on the calling TTY.
    
               Added in version 186.
    
           **--watch**
               Continuously process password requests.
    
               Added in version 186.
    
           **--wall**
               Forward password requests to wall(1) instead of querying the
               user on the calling TTY.
    
               Added in version 186.
    
           **--plymouth**
               Ask question with **plymouth**(8) instead of querying the user on
               the calling TTY.
    
               Added in version 186.
    
           **--console**[=_DEVICE_]
               Ask question on TTY _DEVICE_ instead of querying the user on the
               calling TTY. If _DEVICE_ is not specified, /dev/console will be
               used.
    
               Added in version 186.
    
           **-h** , **--help**
               Print a short help text and exit.
    
           **--version**
               Print a short version string and exit.
    


## EXIT STATUS



           On success, 0 is returned, a non-zero failure code otherwise.
    


## NOTES



            1. Password Agents Specification
               https://systemd.io/PASSWORD_AGENTS/
    


* * *
# flatpak-remote-delete

## NAME



           flatpak-remote-delete - Delete a remote repository
    


## SYNOPSIS



    
           **flatpak remote-delete**[OPTION...] NAME
    


## DESCRIPTION



           Removes a remote repository from the flatpak repository
           configuration.  NAME is the name of an existing remote.
    
           Unless overridden with the **--system** , **--user** , or **--installation**
           options, this command uses either the default system-wide
           installation or the per-user one, depending on which has the
           specified REMOTE.
    


## OPTIONS



           The following options are understood:
    
           **-h** , **--help**
               Show help options and exit.
    
           **-u** , **--user**
               Modify the per-user configuration.
    
           **--system**
               Modify the default system-wide configuration.
    
           **--installation=NAME**
               Modify a system-wide installation specified by NAME among
               those defined in /etc/flatpak/installations.d/. Using
               **--installation=default** is equivalent to using **--system**.
    
           **--force**
               Remove remote even if its in use by installed apps or
               runtimes.
    
           **-v** , **--verbose**
               Print debug information during command processing.
    
           **--ostree-verbose**
               Print OSTree debug information during command processing.
    


## EXAMPLES



           **$ flatpak --user remote-delete dried-raisins**
    


* * *
# mytop

## NAME



           mytop - display MariaDB server performance info like 'top'
    


* * *