title: sympa_msg(8)

summary: Daemon to handle incoming messages

text:
# sympa_msg(8)

## NAME
sympa_msg, sympa_msg.pl - Daemon to handle incoming messages

## SYNOPSIS
"sympa_msg.pl" [ "-d", "--debug" ] [ "-f", "--file"=another.sympa.conf ] [ "-k", "--keepcopy"=directory ] [ "-l", "--lang"=lang ] [ "-m", "--mail" ] [ "-h", "--help" ] [ "-v", "--version" ]

## DESCRIPTION
Sympa_msg.pl is a program which scans permanently the incoming message spool and processes each message.

Messages bound for the lists and authorized sending are modified as necessity and at last stored into digest spool, archive spool and outgoing spool. Those bound for command addresses are interpreted and appropriate actions are taken. Those bound for listmasters or list admins are forwarded to them.

## OPTIONS
Sympa_msg.pl follows the usual GNU command line syntax, with long options starting with two dashes ("--"). A summary of options is included below.

"-d", "--debug"

Enable debug mode.

"-f", "--config="file

Force Sympa to use an alternative configuration file instead of /etc/sympa/sympa.conf.

"-l", "--lang="lang

Set this option to use a language for Sympa. The corresponding gettext catalog file must be located in $LOCALEDIR directory.

"--log_level="level

Sets Sympa log level.

sympa_msg.pl may run in daemon mode with following options.

"--foreground"

The process remains attached to the TTY.

"-k", "--keepcopy="directory

This option tells Sympa to keep a copy of every incoming message, instead of deleting them. `directory' is the directory to store messages.

"-m", "--mail"

Sympa will log calls to sendmail, including recipients. This option is useful for keeping track of each mail sent (log files may grow faster though).

"--service="service

Note: This option was deprecated. Process is dedicated to messages distribution ("process_message"), commands ("process_command") or to automatic lists creation ("process_creation", default three of them).

With following options sympa_msg.pl will print some information and exit.

"-h", "--help"

Print this help message.

"-v", "--version"

Print the version number.

## FILES
/etc/sympa/sympa.conf main configuration file.

$PIDDIR/sympa_msg.pid this file contains the process ID of sympa_msg.pl.

## SEE ALSO
sympa_config(5), sympa(1).

archived(8), bulk(8), bounced(8), sympa_automatic(8), task_manager(8).

Sympa::Spindle::ProcessDigest, Sympa::Spindle::ProcessIncoming.

## HISTORY
sympa.pl was originally written by:

Serge Aumont

Comité Réseau des Universités

Olivier Salaün

Comité Réseau des Universités

As of Sympa 6.2b.4, it was split into three programs: sympa.pl (later renamed to sympa) command line utility, sympa_automatic.pl daemon and sympa_msg.pl daemon.


package: sympa

title: sympa_soap_server(8)

summary: Sympa SOAP server

text:
# sympa_soap_server(8)

## NAME
sympa_soap_server, sympa_soap_server.fcgi - Sympa SOAP server

## DESCRIPTION
Sympa SOAP server allows one to access Sympa service though SOAP.

To know details on Sympa SOAP server, see Sympa Administration Manual: <https://www.sympa.community/manual/customize/soap-api.html>.

## HISTORY
Sympa SOAP server appeared on Sympa 4.0.


title: task_manager(8)

text:
# task_manager(8)

## NAME
task_manager, task_manager.pl - Daemon to process periodical Sympa tasks

## SYNOPSIS
"task_manager.pl" [ "--foreground" ] [ "--debug" ]

## DESCRIPTION
Task_manager is a program which scans permanently the task spool and processes tasks. It also checks configuration of site and every list to create necessary tasks.

## OPTIONS
"-d", "--debug"

Sets the debug mode

"-f", "--config="file

Force task_manager to use an alternative configuration file instead of /etc/sympa/sympa.conf.

"-F", "--foreground"

Prevents the script from being daemonized

"-h", "--help"

Prints this help message.

"--log_level="level

Set log level.

## FILES
$SPOOLDIR/task/ directory for task spool.

$PIDDIR/task_manager.pid this file contains the process ID of task_manager.pl.

## SEE ALSO
sympa_msg(8), wwsympa(8).

Sympa::Spindle::ProcessTask.

## HISTORY
task_manager.pl was contributed by F. Guilleux. It appeared on Sympa 3.3a-vhost.10.


wwsympa

title: wwsympa(8)

summary: WWSympa, Sympa's web interface

text:
# wwsympa(8)

## NAME
wwsympa, wwsympa.fcgi - WWSympa, Sympa's web interface

## DESCRIPTION
This FastCGI script completely handles all aspects of the Sympa web interface.

To know details on WWSympa, see Sympa Administration Manual: <https://www.sympa.community/manual/>.

## HISTORY
WWSympa was initially written by:

- Serge Aumont <sa AT cru.fr>

- Olivier Salaün <os AT cru.fr>

The first alpha version of WWSympa appeared on Sympa 2.3.4.


synaptic

package: synaptic

title: synaptic(8)

text:
# synaptic(8)

## NAME
synaptic - graphical management of software packages

## SYNOPSIS
synaptic [options]

## DESCRIPTION
Synaptic is a frontend for the apt package managent system. It allows you to perform all actions of the command line tool apt-get in a graphical environemnt. This includes installing, upgrading, downgrading and removing of single packages or even upgrading your whole system.

A manual with detailed instructions can be found in the help menu of Synaptic.

## OPTIONS
Synaptic accepts all of the standard Gtk+ toolkit command line options as well as the following:

-f, --filter-file=filename

specify an alternative filter settings file

-i, --initial-filter=int

apply the filter with number int at startup

-o, --option=option

set an internal option (experts only)

## AUTHORS
Synaptic was originally developed by Alfredo K. Kojima <kojima@conectiva.com.br>. His last official release was 0.16. Michael Vogt <mvo@debian.org> took over his CVS version, that already included a nearly complete port to Gtk+. Michael completed the port and added new features. See the NEWS file for the user visible changes from that point on. Conectiva is still involved in the development of synaptic. Gustavo Niemeyer <niemeyer@conectiva.com> is doing a great deal of work.

All development is done at http://savannah.gnu.org/projects/synaptic

This manual page was originally written by Wybo Dekker <wybo@servalys.nl> and Michael Vogt <mvo@debian.org> and modified by Sebastian Heinlein <sebastian.heinlein@campus.lmu.de>.

## COPYRIGHT
Copyright (C) 2001-2004 Conectiva S/A

Copyright (C) 2002-2004 Michael Vogt

There is NO warranty. You may redistribute this software under the terms of the GNU General Public License. For more information about these matters, see the files named COPYING.


csysdig

package: sysdig

title: csysdig(8)

text:
# csysdig(8)

### NAME
csysdig - the ncurses user interface for sysdig

### SYNOPSIS
csysdig [option]... [filter]

### DESCRIPTION
csysdig exports sysdig's functionality through an intuitive and powerful ncurses-based user interface.

csysdig has been designed to mimic tools like top and htop, but it offers richer functionality, including:

•

Support for both live analysis and sysdig trace files. Trace files can come from the same machine or from another machine.

•

Visibility into a broad range of metrics, including CPU, memory, disk I/O, network I/O.

•

Ability to observe input/output activity for processes, files, network connections and more.

•

Ability to drill down into processes, files, network connections and more to further explore their behavior.

•

Full customization support.

•

Support for sysdig's filtering language.

•

Container support by design.

csysdig works on any terminal, and has support for colors and mouse input.

Views

csysdig is based on the concept of 'views', little Lua scripts that determine how metrics are collected, processed and represented on screen. Including a new visualization to csysdig doesn't require to update the program, and is simply a matter of adding a new view. Views rely on the sysdig processing engine, and this means that they can include any sysdig filter field. Views are located in the sysdig chisel directory path, usually /usr/share/sysdig/chisels and ~/.chisels.

### BASIC USAGE
Here are some basic tips to get you started with sysdig:

1.

If you run csysdig without arguments, it will display live system data, updating every 2 seconds. To analyze a trace file, use the -r command line flag.

2.

You can switch to a different view by using the F2 key.

3.

You can drill down into a selection by clicking enter. You can navigate back by typing backspace.

4.

You can observe input/output for the currently selected entity by typing F5

5.

You can see sysdig events for the currently selected entity by typing F6

### DRILLING DOWN
You drill down by selecting an element in a view and then clicking enter. Once inside a selection, you can switch to a different view, and the new view will be applied in the context of the selection. For example, if you drill down into a process called foo and then switch to the Connections view, the output will include only the connections made or received by foo.

To drill down multiple times, keep clicking enter. For example, you can click on a container in the Containers view to get the processes running inside it, and then click on one of the processes to see its threads.

### ACTIONS AND HOTKEYS
Each view has a list of command lines that can be executed in the context of the current selection by pressing 'hotkeys'. For example, pressing 'k' in the Processes view kills the selected process, pressing 'b' in the Containers view opens a bash shell in the selected container.

Each view supports different actions. You can see which actions a view supports by pressing F8. You can customize the view's actions by editing the view's Lua file.

### CONTAINERS SUPPORT
Starting csysdig with the -pc command line switch will cause many of the views to include additional container information. For example, the Processes will include a column showing the container the process belongs to. Similarly, the Connections view will show which container each connection belongs to.

### Views Window
Arrows, PgUP, PgDn, Home, End

Change the selection and scroll view content, both vertically and horizontally.

Enter

Drill down into the currently highlighted entry.

Backspace

Navigate back to the previous view.

F2

Show the view picker. This will let you switch to another view.

CTRL+F /

Incremental search in the list of view entries.

F4

Incremental filtering of the view entries.

F5, e

'echo FDs' for the selection, i.e. view FD input/output for the currently highlighted entry.

F6, d

'dig' into the selection, i.e. view sysdig events for the currently highlighted entry. Refer to the sysdig man page to learn about interpreting the content of this window.

F7

Show the help page for the currently displayed view.

F8

Open the view's actions panel.

F9, >

Open the column sort panel.

F10, q

Quit.

DEL, c

For views that are listing elements without aggregating them by key (identifiable by yellow column headers), this command clears the view content.

p

Pause screen updates.

<shift> <1-9>

sort column <n>

F1, h, ?

Show the help screen.

### Echo and sysdig Windows
Arrows, PgUP, PgDn, Home, End

Scroll the page content.

Backspace

Navigate back to the previous view.

CTRL+F /

Search inside the window content.

F3

Find Next.

F2

Chose the output rendering format. Options are 'Dotted ASCII' (non-printable binary bytes are rendered as dots), 'Printable ASCII' (non-printable binary bytes are not included and line endings are rendered accurately) and 'Hex' (dotted ASCII representation is included together with the Hexadecimal rendering of the buffers).

DEL, c

Clear the screen content.

p

Pause screen updates.

CTRL+G

Go to line.

### Spectrogram Window
F2

Show the view picker. This will let you switch to another view.

p

Pause/Resume the visualization.

Backspace

Navigate back to the previous view.

### MOUSE USAGE
•

Clicking on column headers lets you sort the table.

•

Double clicking on row entries performs a drill down.

•

Clicking on the filter string at the top of the screen (the text after 'Filter:') lets you change the sysdig filter and customize the view content.

•

You can use the mouse on the entries in the menu at the bottom of the screen to perform their respective actions.

### COMMAND LINE OPTIONS
-d period, --delay=period

Set the delay between updates, in milliseconds (by default = 2000). This works similarly to the -d option in top.

-E, --exclude-users

Don't create the user/group tables by querying the OS when sysdig starts. This also means that no user or group info will be written to the tracefile by the -w flag. The user/group tables are necessary to use filter fields like user.name or group.name. However, creating them can increase sysdig's startup time.

--force-term-compat

Try to configure simple terminal settings (xterm-1002) that work better with terminals like putty. Try to use this flag if you experience terminal issues like the mouse not working.

-h, --help

Print this page

-k, --k8s-api Enable Kubernetes support by connecting to the API server specified as argument. E.g. "<http://admin:password@127.0.0.1:8080>". The API server can also be specified via the environment variable SYSDIG_K8S_API.

-K btfile | certfile:keyfile[#password][:cacertfile], --k8s-api-cert=_btfile | certfile:keyfile[#password][:cacertfile]_ Use the provided files names to authenticate user and (optionally) verify the K8S API server identity. Each entry must specify full (absolute, or relative to the current directory) path to the respective file. Private key password is optional (needed only if key is password protected). CA certificate is optional. For all files, only PEM file format is supported. Specifying CA certificate only is obsoleted - when single entry is provided for this option, it will be interpreted as the name of a file containing bearer token. Note that the format of this command-line option prohibits use of files whose names contain ':' or '#' characters in the file name. Option can also be provided via the environment variable SYSDIG_K8S_API_CERT.

-l, --list

List all the fields that can be used in views.

--logfile file

Print program logs into the given file.

-m url[,marathon-url], --mesos-api=_url[,marathon-url]_ Enable Mesos support by connecting to the API server specified as argument (e.g. <http://admin:password@127.0.0.1:5050>). Mesos url is required. Marathon url is optional, defaulting to auto-follow - if Marathon API server is not provided, csysdig will attempt to retrieve (and subsequently follow, if it migrates) the location of Marathon API server from the Mesos master. Note that, with auto-follow, csysdig will likely receive a cluster internal IP address for Marathon API server, so running csysdig with Marathon auto-follow from a node that is not part of Mesos cluster may not work. Additionally, running csysdig with Mesos support on a node that has no containers managed by Mesos is of limited use because, although cluster metadata will be collected, there will be no Mesos/Marathon filtering capability. The API servers can also be specified via the environment variable SYSDIG_MESOS_API.

-n num, --numevents=num

Stop capturing after num events

--page-faults Capture user/kernel major/minor page faults

-pc, -pcontainers_

Instruct csysdig to use a container-friendly format in its views. This will cause several of the views to contain additional container-related columns.

-R, --resolve-ports Resolve port numbers to names.

-r readfile, --read=readfile

Read the events from readfile.

-s len, --snaplen=len

Capture the first len bytes of each I/O buffer. By default, the first 80 bytes are captured. Use this option with caution, it can generate huge trace files.

-T, --force-tracers-capture

Tell the driver to make sure full buffers are captured from /dev/null, to make sure that tracers are completely captured. Note that sysdig will enable extended /dev/null capture by itself after detecting that tracers are written there, but that could result in the truncation of some tracers at the beginning of the capture. This option allows preventing that.

-v view_id, --views=view_id

Run the view with the given ID when csysdig starts. View IDs can be found in the view documentation pages in csysdig. Combine this option with a command line filter for complete output customization.

--version

Print version number.

### FILTERING
Similarly to what you do with sysdig, you can specify a filter on the command line to restrict the events that csysdig processes. To modify the filter while the program is running, or to add a filter at runtime, click on the filter text in the UI with the mouse.

### CUSTOMIZING CSYSDIG
csysdig is completely customizable. This means that you can modify any of the csysdig views, and even create your own views. Like sysdig chisels, csysdig views are Lua scripts. Full information can be found at the following github wiki page: <https://github.com/draios/sysdig/wiki/csysdig-View-Format-Reference>.

### FILES
/usr/share/sysdig/chisels

The global views directory.

~/.chisels

The personal views directory.

### AUTHOR
Draios Inc. (dba Sysdig) <info@sysdig.com>

### SEE ALSO
sysdig(8), strace(8), tcpdump(8), lsof(8)


sysdig

title: sysdig(8)

text:
# sysdig(8)

### NAME
sysdig - the definitive system and process troubleshooting tool

### SYNOPSIS
sysdig [option]... [filter]

### DESCRIPTION
Note: if you are interested in an easier to use interface for the sysdig functionality, use the csysdig command line utility.

sysdig is a tool for system troubleshooting, analysis and exploration. It can be used to capture, filter and decode system calls and other OS events. sysdig can be both used to inspect live systems, or to generate trace files that can be analyzed at a later stage.

sysdig includes a powerful filtering language, has customizable output, and can be extended through Lua scripts, called chisels.

Output format

By default, sysdig prints the information for each captured event on a single line, with the following format:

*%evt.num %evt.time %evt.cpu %proc.name (%thread.tid) %evt.dir %evt.type %evt.info

where:

•

evt.num is the incremental event number

•

evt.time is the event timestamp

•

evt.cpu is the CPU number where the event was captured

•

proc.name is the name of the process that generated the event

•

thread.tid id the TID that generated the event, which corresponds to the PID for single thread processes

•

evt.dir is the event direction, > for enter events and < for exit events

•

evt.type is the name of the event, e.g. 'open' or 'read'

•

evt.args is the list of event arguments.

The output format can be customized with the -p switch, using any of the fields listed by 'sysdig -l'.

Using -pc or -pcontainer, the default format will be changed to a container-friendly one:

*%evt.num %evt.time %evt.cpu %container.name (%container.id) %proc.name (%thread.tid:%thread.vtid) %evt.dir %evt.type %evt.info

Trace Files

A trace file can be created using the -w switch:

$ sysdig -w trace.scap

The -s switch can be used to specify how many bytes of each data buffer should be saved to disk. And filters can be used to save only certain events to disk:

$ sysdig -s 2000 -w trace.scap proc.name=cat

Trace files can be read this using the -r switch:

$ sysdig -r trace.scap

Filtering

sysdig filters are specified at the end of the command line. The simplest filter is a basic field-value check:

$ sysdig proc.name=cat

The list of available fields can be obtained with 'sysdig -l'. Filter expressions can use one of these comparison operators: =, !=, <, <=, >, >=, contains, icontains, in and exists. e.g.

$ sysdig fd.name contains /etc $ sysdig "evt.type in ( 'select', 'poll' )" $ sysdig proc.name exists

Multiple checks can be combined through brackets and the following boolean operators: and, or, not. e.g.

$ sysdig "not (fd.name contains /proc or fd.name contains /dev)"

Chisels

sysdig's chisels are little scripts that analyze the sysdig event stream to perform useful actions. To get the list of available chisels, type

$ sysdig -cl

To get details about a specific chisel, type

$ sysdig -i spy_ip

To run one of the chisels, you use the -c flag, e.g.

$ sysdig -c topfiles_bytes

If a chisel needs arguments, you specify them after the chisel name:

$ sysdig -c spy_ip 192.168.1.157

If a chisel has more than one argument, specify them after the chisel name, enclosed in quotes:

$ sysdig -c chisel_name "arg1 arg2 arg3"

Chisels can be combined with filters:

$ sysdig -c topfiles_bytes "not fd.name contains /dev"

### OPTIONS
-A, --print-ascii Only print the text portion of data buffers, and echo end-of-lines. This is useful to only display human-readable data.

-b, --print-base64 Print data buffers in base64. This is useful for encoding binary data that needs to be used over media designed to handle textual data (i.e., terminal or json).

-c chiselname chiselargs, --chisel=chiselname chiselargs run the specified chisel. If the chisel require arguments, they must be specified in the command line after the name.

-C filesize Break a capture into separate files, and limit the size of each file based on the specified number of megabytes. The units of filesize are millions of bytes (10^6, not 2^20). Use in conjunction with -W to enable automatic file rotation. Otherwise, new files will continue to be created until the capture is manually stopped.

Files will have the name specified by -w with a counter added starting at 0.

-cl, --list-chisels lists the available chisels. Sysdig looks for chisels in the following directories: ./chisels, ~/.chisels and /usr/share/sysdig/chisels.

-d, --displayflt Make the given filter a display one. Setting this option causes the events to be filtered after being parsed by the state system. Events are normally filtered before being analyzed, which is more efficient, but can cause state (e.g. FD names) to be lost.

-D, --debug Capture events about sysdig itself, display internal events in addition to system events, and print additional logging on standard error.

-E, --exclude-users Don't create the user/group tables by querying the OS when sysdig starts. This also means that no user or group info will be written to the tracefile by the -w flag. The user/group tables are necessary to use filter fields like user.name or group.name. However, creating them can increase sysdig's startup time. Moreover, they contain information that could be privacy sensitive.

-e numevents Break a capture into separate files, and limit the size of each file based on the specified number of events. Use in conjunction with -W to enable automatic file rotation. Otherwise, new files will continue to be created until the capture is manually stopped.

Files will have the name specified by -w with a counter added starting at 0.

-F, --fatfile Enable fatfile mode. When writing in fatfile mode, the output file will contain events that will be invisible when reading the file, but that are necessary to fully reconstruct the state. Fatfile mode is useful when saving events to disk with an aggressive filter. The filter could drop events that would cause the state to be updated (e.g. clone() or open()). With fatfile mode, those events are still saved to file, but 'hidden' so that they won't appear when reading the file. Be aware that using this flag might generate substantially bigger traces files.

--filter-proclist apply the filter to the process table. A full dump of /proc is typically included in any trace file to make sure all the state required to decode events is in the file. This could cause the file to contain unwanted or sensitive information. Using this flag causes the command line filter to be applied to the /proc dump as well.

-G numseconds Break a capture into separate files, and limit the size of each file based on the specified number of seconds. Use in conjunction with -W to enable automatic file rotation. Otherwise, new files will continue to be created until the capture is manually stopped.

Files will have the name specified by -w which should include a time format as defined by strftime(3). If no time format is specified, a counter will be used.

-h, --help Print this page

-H pluginname[:initconfig], --plugin pluginname[:initconfig] Registers a plugin, using the passed init config if present. A path can also be used as pluginname. The format of initconf is controlled by the plugin, refer to each plugin's documentation to learn about it.

-I pluginname[:openparams], --input pluginname[:openparams] Capture events using the plugin with name pluginname, passing to the plugin the openparams string as parameters. The format of inputargs is controller by the plugin, refer to each plugin's documentation to learn about it. The event sources available for capture vary depending on which plugins have been installed. You can list the plugins that have been loaded by using the -Il flag.

-Il, --list-inputs List the loaded plugins. Sysdig looks for plugins in the following directories: ./plugins, ~/.plugins, /usr/share/sysdig/plugins.

--plugin-config-file Load the plugin configuration from a Falco-compatible yaml config file. Mixing this option with '-H' or '-I' is unsupported. See the plugin section in <https://falco.org/docs/configuration/> for additional informations.

-i chiselname, --chisel-info=_chiselname_ Get a longer description and the arguments associated with a chisel found in the -cl option list.

-j, --json Emit output as json, data buffer encoding will depend from the print format selected.

-k, --k8s-api Enable Kubernetes support by connecting to the API server specified as argument. E.g. "<http://admin:password@127.0.0.1:8080>". The API server can also be specified via the environment variable SYSDIG_K8S_API.

-K btfile | certfile:keyfile[#password][:cacertfile], --k8s-api-cert=_btfile | certfile:keyfile[#password][:cacertfile]_ Use the provided files names to authenticate user and (optionally) verify the K8S API server identity. Each entry must specify full (absolute, or relative to the current directory) path to the respective file. Private key password is optional (needed only if key is password protected). CA certificate is optional. For all files, only PEM file format is supported. Specifying CA certificate only is obsoleted - when single entry is provided for this option, it will be interpreted as the name of a file containing bearer token. Note that the format of this command-line option prohibits use of files whose names contain ':' or '#' characters in the file name. Option can also be provided via the environment variable SYSDIG_K8S_API_CERT.

-L, --list-events List the events that the engine supports

-l, --list List the fields that can be used for filtering and output formatting. Use -lv to get additional information for each field.

--list-markdown Like -l, but produces markdown output

-m url[,marathon-url], --mesos-api=_url[,marathon-url]_ Enable Mesos support by connecting to the API server specified as argument (e.g. <http://admin:password@127.0.0.1:5050>). Mesos url is required. Marathon url is optional, defaulting to auto-follow - if Marathon API server is not provided, sysdig will attempt to retrieve (and subsequently follow, if it migrates) the location of Marathon API server from the Mesos master. Note that, with auto-follow, sysdig will likely receive a cluster internal IP address for Marathon API server, so running sysdig with Marathon auto-follow from a node that is not part of Mesos cluster may not work. Additionally, running sysdig with Mesos support on a node that has no containers managed by Mesos is of limited use because, although cluster metadata will be collected, there will be no Mesos/Marathon filtering capability. The API servers can also be specified via the environment variable SYSDIG_MESOS_API.

-M num_seconds Stop collecting after reaching

-n num, --numevents=num

Stop capturing after num events

--page-faults Capture user/kernel major/minor page faults

-P, --progress

Print progress on stderr while processing trace files.

-p outputformat, --print=outputformat

Specify the format to be used when printing the events. With -pc or -pcontainer will use a container-friendly format. With -pk or -pkubernetes will use a kubernetes-friendly format. With -pm or -pmesos will use a mesos-friendly format. Specifying -pp on the command line will cause sysdig to print the default command line format and exit.

-q, --quiet

Don't print events on the screen. Useful when dumping to disk.

-r readfile, --read=readfile

Read the events from readfile.

-R, --resolve-ports Resolve port numbers to names.

-S, --summary

print the event summary (i.e. the list of the top events) when the capture ends.

-s len, --snaplen=len

Capture the first len bytes of each I/O buffer. By default, the first 80 bytes are captured. Use this option with caution, it can generate huge trace files.

-t timetype, --timetype=timetype

Change the way event time is displayed. Accepted values are h for human-readable string, a for absolute timestamp from epoch, r for relative time from the first displayed event, d for delta between event enter and exit, and D for delta from the previous event.

-T, --force-tracers-capture

Tell the driver to make sure full buffers are captured from /dev/null, to make sure that tracers are completely captured. Note that sysdig will enable extended /dev/null capture by itself after detecting that tracers are written there, but that could result in the truncation of some tracers at the beginning of the capture. This option allows preventing that.

--unbuffered

Turn off output buffering. This causes every single line emitted by sysdig to be flushed, which generates higher CPU usage but is useful when piping sysdig's output into another process or into a script.

-v, --verbose

Verbose output. This flag will cause the full content of text and binary buffers to be printed on screen, instead of being truncated to 40 characters. Note that data buffers length is still limited by the snaplen (refer to the -s flag documentation) -v will also make sysdig print some summary information at the end of the capture.

--version

Print version number.

-w writefile, --write=writefile

Write the captured events to writefile.

-W num

Turn on file rotation for continuous capture, and limit the number of files created to the specified number. Once the cap is reached, older files will be overwritten (ring buffer). Use in conjunction with the -C / -G / -e options to limit the size of each file based on number of megabytes, seconds, and/or events (respectively).

-x, --print-hex

Print data buffers in hex.

-X, --print-hex-ascii

Print data buffers in hex and ASCII.

-z, --compress

Used with -w, enables compression for tracefiles.

### EXAMPLES
Capture all the events from the live system and print them to screen

$ sysdig

Capture all the events from the live system and save them to disk

$ sysdig -w dumpfile.scap

Capture all the events in the latest 24 hours and save them to disk organized in files containing 1 hour of system activity each

$ sysdig -G 3600 -W 24 -w dumpfile.scap

Read events from a file and print them to screen

$ sysdig -r dumpfile.scap

Prepare a sanitized version of a system capture

$ sysdig -r dumpfile.scap 'not evt.buffer contains foo' -w cleandump.scap

Print all the open system calls invoked by cat

$ sysdig proc.name=cat and evt.type=open

Print the name of the files opened by cat

$ sysdig -p"%evt.arg.name" proc.name=cat and evt.type=open

List the available chisels

$ sysdig -cl

Use the spy_ip chisel to look at the data exchanged with 192.168.1.157:

$ sysdig -c spy_ip 192.168.1.157

### FILES
/usr/share/sysdig/chisels

The global chisels directory.

~/.chisels

The personal chisels directory.

### BUGS
•

sysdig and its chisels are designed to be used with LuaJIT in Lua 5.1 mode. While it is possible to use sysdig with LuaJIT in Lua 5.2 mode or regular Lua, some chisels may not work as expected.

### AUTHOR
Draios Inc. aka sysdig <info@sysdigcloud.com>

### SEE ALSO
csysdig(8), strace(8), tcpdump(8), lsof(8)


syslog-ng

package: syslog-ng

title: syslog-ng(8)

summary: syslog\-ng system logger application

text:
# syslog-ng(8)

## NAME
syslog-ng - syslog-ng system logger application

## SYNOPSIS
syslog-ng [options]

## DESCRIPTION
This manual page is only an abstract, for the complete documentation of syslog-ng, see The Administrator Guide[1] or the official syslog-ng website[2].

The application is a flexible and highly scalable system logging application. Typically, syslog-ng is used to manage log messages and implement centralized logging, where the aim is to collect the log messages of several devices on a single, central log server. The different devices - called syslog-ng clients - all run syslog-ng, and collect the log messages from the various applications, files, and other sources. The clients send all important log messages to the remote syslog-ng server, where the server sorts and stores them.

## OPTIONS
--caps

Run process with the specified POSIX capability flags.

•If the --no-caps option is not set, and the host supports CAP_SYSLOG, uses the following capabilities: "cap_net_bind_service, cap_net_broadcast, cap_net_raw, cap_dac_read_search, cap_dac_override, cap_chown, cap_fowner=p cap_syslog=ep"

•If the --no-caps option is not set, and the host does not support CAP_SYSLOG, uses the following capabilities: "cap_net_bind_service, cap_net_broadcast, cap_net_raw,cap_dac_read_search, cap_dac_override, cap_chown, cap_fowner=p cap_sys_admin=ep"

For example:

```
/usr/sbin/syslog-ng -Fv --caps cap_sys_admin,cap_chown,cap_dac_override,cap_net_bind_service,cap_fowner=pi
```

Note that the capabilities are not case sensitive, the following command is also good: /usr/sbin/syslog-ng -Fv --caps CAP_SYS_ADMIN,CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_NET_BIND_SERVICE,CAP_FOWNER=pi

For details on the capability flags, see the following man pages: cap_from_text(3) and capabilities(7)

--cfgfile <file> or -f <file>

Use the specified configuration file.

--chroot <dir> or -C <dir>

Change root to the specified directory. The configuration file is read after chrooting so, the configuration file must be available within the chroot. That way it is also possible to reload the syslog-ng configuration after chrooting. However, note that the --user and --group options are resolved before chrooting.

--control <file> or -c <file>

Set the location of the syslog-ng control socket. Default value: /var/run/syslog-ng.ctl

--debug or -d

Start syslog-ng in debug mode.

--enable-core

Enable syslog-ng to write core files in case of a crash to help support and debugging.

--fd-limit <number>

Set the minimal number of required file descriptors (fd-s). This sets how many files syslog-ng can keep open simultaneously. Default value: 4096. Note that this does not override the global ulimit setting of the host.

--foreground or -F

Do not daemonize, run in the foreground. When running in the foreground, starts from the current directory ($CWD) so it can create core files (normally, starts from $PREFIX/var).

--group <group> or -g <group>

Switch to the specified group after initializing the configuration file.

--help or -h

Display a brief help message.

--module-registry

Display the list and description of the available modules. Available only in and later.

--no-caps

Run syslog-ng as root, without capability-support. This is the default behavior. On Linux, it is possible to run syslog-ng as non-root with capability-support if syslog-ng was compiled with the --enable-linux-caps option enabled. (Execute syslog-ng --version to display the list of enabled build parameters.) To run with specific capabilities, use the --caps option.

--persist-file <persist-file> or -R <persist-file>

Set the path and name of the syslog-ng.persist file where the persistent options and data are stored.

--pidfile <pidfile> or -p <pidfile>

Set path to the PID file where the pid of the main process is stored.

--preprocess-into <output-file>

After processing the configuration file and resolving included files and variables, write the resulting configuration into the specified output file. Available only in and later.

--process-mode <mode>

Sets how to run syslog-ng: in the foreground (mainly used for debugging), in the background as a daemon, or in safe-background mode. By default, syslog-ng runs in safe-background mode. This mode creates a supervisor process called supervising syslog-ng , that restarts syslog-ng if it crashes.

--stderr or -e

Log internal messages of syslog-ng to stderr. Mainly used for debugging purposes in conjunction with the --foreground option. If not specified, syslog-ng will log such messages to its internal source.

--syntax-only or -s

Verify that the configuration file is syntactically correct and exit.

--user <user> or -u <user>

Switch to the specified user after initializing the configuration file (and optionally chrooting). Note that it is not possible to reload the syslog-ng configuration if the specified user has no privilege to create the /dev/log file.

--verbose or -v

Enable verbose logging used to troubleshoot syslog-ng.

--version or -V

Display version number and compilation information, and also the list and short description of the available modules. For detailed description of the available modules, see the --module-registry option.

--worker-threads

Sets the number of worker threads can use, including the main thread. Note that certain operations in can use threads that are not limited by this option. This setting has effect only when is running in multithreaded mode. Available only in and later. See The 3.34 Administrator Guide for details.

## FILES
/usr/

/etc/syslog-ng/syslog-ng.conf

## SEE ALSO
syslog-ng.conf(5)

Note

For the detailed documentation of see The 3.34 Administrator Guide[3]

If you experience any problems or need help with syslog-ng, visit the syslog-ng mailing list[4].

For news and notifications about of syslog-ng, visit the syslog-ng blogs[5].

## AUTHOR
This manual page was written by the Balabit Documentation Team <documentation@balabit.com>.

## NOTES
1.

The Administrator Guide

https://www.balabit.com/support/documentation/

2.

the official syslog-ng website

https://www.balabit.com/log-management

3.

The 3.34 Administrator Guide

https://www.balabit.com/documents/syslog-ng-ose-latest-guides/en/syslog-ng-ose-guide-admin/html/index.html

4.

syslog-ng mailing list

https://lists.balabit.hu/mailman/listinfo/syslog-ng

5.

syslog-ng blogs

https://syslog-ng.org/blogs/


sysklogd

package: syslogd

title: sysklogd(8)

summary: Linux system logging utilities.

text:
# sysklogd(8)

## NAME
sysklogd - Linux system logging utilities.

## SYNOPSIS
syslogd [ -4 ] [ -6 ] [ -A ] [ -a socket ] [ -c ] [ -d ] [ -f config file ] [ -h ] [ -i IP address ] [ -l hostlist ] [ -m interval ] [ -n ] [ -p socket ] [ -P directory ] [ -r ] [ -s domainlist ] [ -u username ] [ -j chroot_dir ] [ -v ]

## DESCRIPTION
Sysklogd provides two system utilities which provide support for system logging and kernel message trapping. Support of both internet and unix domain sockets enables this utility package to support both local and remote logging.

System logging is provided by a version of syslogd(8) derived from the stock BSD sources. Support for kernel logging is provided by the klogd(8) utility which allows kernel logging to be conducted in either a standalone fashion or as a client of syslogd.

Syslogd provides a kind of logging that many modern programs use. Every logged message contains at least a time and a hostname field, normally a program name field, too, but that depends on how trusty the logging program is.

While the syslogd sources have been heavily modified a couple of notes are in order. First of all there has been a systematic attempt to insure that syslogd follows its default, standard BSD behavior. The second important concept to note is that this version of syslogd interacts transparently with the version of syslog found in the standard libraries. If a binary linked to the standard shared libraries fails to function correctly we would like an example of the anomalous behavior.

The main configuration file /etc/syslog.conf or an alternative file, given with the -f option, is read at startup. Any lines that begin with the hash mark (``#'') and empty lines are ignored. If an error occurs during parsing the whole line is ignored.

## OPTIONS
-4

Force syslogd to use IPv4 addresses only.

-6

Force syslogd to use IPv6 addresses only.

-A

Ordinarily, syslogd tries to send the message to only one address even if the host has more than one A or AAAA record. If this option is specified, syslogd tries to send the message to all addresses.

-a socket

Using this argument you can specify additional sockets from that syslogd has to listen to. This is needed if you're going to let some daemon run within a chroot() environment. You can use up to 19 additional sockets. If your environment needs even more, you have to increase the symbol MAXFUNIX within the syslogd.c source file. An example for a chroot() daemon is described by the people from OpenBSD at <http://www.guides.sk/psionic/dns/>.

-c

Disable the repeating line compression that normally suppresses the repeated lines and logs a message such as 'last message repeated 124 times'. With this option, all repeated lines will be logged.

-d

Turns on debug mode. Using this the daemon will not proceed a fork(2) to set itself in the background, but opposite to that stay in the foreground and write much debug information on the current tty. See the DEBUGGING section for more information.

-f config file

Specify an alternative configuration file instead of /etc/syslog.conf, which is the default.

-h

By default syslogd will not forward messages it receives from remote hosts. Specifying this switch on the command line will cause the log daemon to forward any remote messages it receives to forwarding hosts which have been defined. This can cause syslog loops that fill up hard disks quite fast and thus needs to be used with caution.

-i IP address

If syslogd is configured to accept log input from a UDP port, specify an IP address to bind to, rather than the default of INADDR_ANY. The address must be in dotted quad notation, DNS host names are not allowed.

-l hostlist

Specify a hostname that should be logged only with its simple hostname and not the fqdn. Multiple hosts may be specified using the colon (``:'') separator.

-m interval

The syslogd logs a mark timestamp regularly. The default interval between two -- MARK -- lines is 20 minutes. This can be changed with this option. Setting the interval to zero turns it off entirely. Depending on other log messages generated these lines may not be written consecutively. The -- MARK -- message is only written if the log file hasn't been touched in interval/2 minutes.

-n

Avoid auto-backgrounding. This is needed especially if the syslogd is started and controlled by init(8).

-p socket

You can specify an alternative unix domain socket instead of /dev/log.

-P directory

Using this argument you can specify directory with symlinks to additional sockets from that syslogd has to listen to. This is convenient method if you're going to let several daemons run within different chrooted environments.

-r

This option will enable the facility to receive message from the network using an internet domain socket with the syslog service (see services(5)). The default is to not receive any messages from the network. This option is introduced in version 1.3 of the sysklogd package. Please note that the default behavior is the opposite of how older versions behave, so you might have to turn this on.

-s domainlist

Specify a domainname that should be stripped off before logging. Multiple domains may be specified using the colon (``:'') separator. Please be advised that no sub-domains may be specified but only entire domains. For example if -s north.de is specified and the host logging resolves to satu.infodrom.north.de no domain would be cut, you will have to specify two domains like: -s north.de:infodrom.north.de.

-u username

This causes the syslogd daemon to become the named user before starting up logging. Note that when this option is in use, syslogd will open all log files as root when the daemon is first started; however, after a SIGHUP the files will be reopened as the non-privileged user. You should take this into account when deciding the ownership of the log files.

-j chroot_dir

Tells syslogd daemon to chroot(2) into this directory after initializing. This option is only valid if the -u option is also used to run syslogd without root privileges. Note that the use of this option will prevent SIGHUP from working which makes daemon reload practically impossible.

-v

Print version and exit.

## SIGNALS
Syslogd reacts to a set of signals. You may easily send a signal to syslogd using the following:

```
kill -SIGNAL `cat /var/run/syslogd.pid`
```

SIGHUP

This lets syslogd perform a re-initialization. All open files are closed, the configuration file (default is /etc/syslog.conf) will be reread and the syslog(3) facility is started again.

SIGTERM

The syslogd will die.

SIGINT, SIGQUIT

If debugging is enabled these are ignored, otherwise syslogd will die.

SIGUSR1

Switch debugging on/off. This option can only be used if syslogd is started with the -d debug option.

SIGCHLD

Wait for childs if some were born, because of wall'ing messages.

## CONFIGURATION FILE SYNTAX DIFFERENCES
Syslogd uses a slightly different syntax for its configuration file than the original BSD sources. Originally all messages of a specific priority and above were forwarded to the log file.

For example the following line caused ALL output from daemons using the daemon facilities (debug is the lowest priority, so every higher will also match) to go into /usr/adm/daemons:

```
	# Sample syslog.conf
	daemon.debug			/usr/adm/daemons
```

Under the new scheme this behavior remains the same. The difference is the addition of four new specifiers, the asterisk (*) wildcard, the equation sign (=), the exclamation mark (!), and the minus sign (-).

The * specifies that all messages for the specified facility are to be directed to the destination. Note that this behavior is degenerate with specifying a priority level of debug. Users have indicated that the asterisk notation is more intuitive.

The = wildcard is used to restrict logging to the specified priority class. This allows, for example, routing only debug messages to a particular logging source.

For example the following line in syslog.conf would direct debug messages from all sources to the /usr/adm/debug file.

```
	# Sample syslog.conf
	*.=debug			/usr/adm/debug
```

The ! is used to exclude logging of the specified priorities. This affects all (!) possibilities of specifying priorities.

For example the following lines would log all messages of the facility mail except those with the priority info to the /usr/adm/mail file. And all messages from news.info (including) to news.crit (excluding) would be logged to the /usr/adm/news file.

```
	# Sample syslog.conf
	mail.*;mail.!=info		/usr/adm/mail
	news.info;news.!crit	/usr/adm/news
```

You may use it intuitively as an exception specifier. The above mentioned interpretation is simply inverted. Doing that you may use

```
	mail.none
```

or

```
	mail.!*
```

or

```
	mail.!debug
```

to skip every message that comes with a mail facility. There is much room to play with it. :-)

The - may only be used to prefix a filename if you want to omit sync'ing the file after every write to it.

This may take some acclimatization for those individuals used to the pure BSD behavior but testers have indicated that this syntax is somewhat more flexible than the BSD behavior. Note that these changes should not affect standard syslog.conf(5) files. You must specifically modify the configuration files to obtain the enhanced behavior.

## SUPPORT FOR REMOTE LOGGING
These modifications provide network support to the syslogd facility. Network support means that messages can be forwarded from one node running syslogd to another node running syslogd where they will be actually logged to a disk file.

To enable this you have to specify the -r option on the command line. The default behavior is that syslogd won't listen to the network.

The strategy is to have syslogd listen on a unix domain socket for locally generated log messages. This behavior will allow syslogd to inter-operate with the syslog found in the standard C library. At the same time syslogd listens on the standard syslog port for messages forwarded from other hosts. To have this work correctly the services(5) files (typically found in /etc) must have the following entry:

```
	syslog          514/udp
```

If this entry is missing syslogd neither can receive remote messages nor send them, because the UDP port cant be opened. Instead syslogd will die immediately, blowing out an error message.

To cause messages to be forwarded to another host replace the normal file line in the syslog.conf file with the name of the host to which the messages is to be sent prepended with an @.

For example, to forward ALL messages to a remote host use the following syslog.conf entry:

```
	# Sample syslogd configuration file to
	# messages to a remote host forward all.
	*.*			@hostname
```

To forward all kernel messages to a remote host the configuration file would be as follows:

```
	# Sample configuration file to forward all kernel
	# messages to a remote host.
	kern.*		@hostname
```

If the remote hostname cannot be resolved at startup, because the name-server might not be accessible (it may be started after syslogd) you don't have to worry. Syslogd will retry to resolve the name ten times and then complain. Another possibility to avoid this is to place the hostname in /etc/hosts.

With normal syslogds you would get syslog-loops if you send out messages that were received from a remote host to the same host (or more complicated to a third host that sends it back to the first one, and so on). In my domain (Infodrom Oldenburg) we accidently got one and our disks filled up with the same single message. :-(

To avoid this no messages received from a remote host are sent out to another (or the same) remote host anymore. If you experience are setup in which you need this behaviour, please use the -h command line switch. However, this option needs to be handled with caution since a syslog loop can fill up hard disks quite fast.

If the remote host is located in the same domain as the host, syslogd is running on, only the simple hostname will be logged instead of the whole fqdn.

In a local network you may provide a central log server to have all the important information kept on one machine. If the network consists of different domains you don't have to complain about logging fully qualified names instead of simple hostnames. You may want to use the strip-domain feature -s of this server. You can tell the syslogd to strip off several domains other than the one the server is located in and only log simple hostnames.

Using the -l option there's also a possibility to define single hosts as local machines. This, too, results in logging only their simple hostnames and not the fqdns.

The UDP socket used to forward messages to remote hosts or to receive messages from them is only opened when it is needed. In releases prior to 1.3-23 it was opened every time but not opened for reading or forwarding respectively.

## OUTPUT TO NAMED PIPES (FIFOs)
This version of syslogd has support for logging output to named pipes (fifos). A fifo or named pipe can be used as a destination for log messages by prepending a pipy symbol (``|'') to the name of the file. This is handy for debugging. Note that the fifo must be created with the mkfifo command before syslogd is started.

The following configuration file routes debug messages from the kernel to a fifo:

```
	# Sample configuration to route kernel debugging
	# messages ONLY to /usr/adm/debug which is a
	# named pipe.
	kern.=debug			|/usr/adm/debug
```

## INSTALLATION CONCERNS
There is probably one important consideration when installing this version of syslogd. This version of syslogd is dependent on proper formatting of messages by the syslog function. The functioning of the syslog function in the shared libraries changed somewhere in the region of libc.so.4.[2-4].n. The specific change was to null-terminate the message before transmitting it to the /dev/log socket. Proper functioning of this version of syslogd is dependent on null-termination of the message.

This problem will typically manifest itself if old statically linked binaries are being used on the system. Binaries using old versions of the syslog function will cause empty lines to be logged followed by the message with the first character in the message removed. Relinking these binaries to newer versions of the shared libraries will correct this problem.

Both the syslogd(8) and the klogd(8) can either be run from init(8) or started as part of the rc.* sequence. If it is started from init the option -n must be set, otherwise you'll get tons of syslog daemons started. This is because init(8) depends on the process ID.

## SECURITY THREATS
There is the potential for the syslogd daemon to be used as a conduit for a denial of service attack. Thanks go to John Morrison (jmorriso@rflab.ee.ubc.ca) for alerting me to this potential. A rogue program(mer) could very easily flood the syslogd daemon with syslog messages resulting in the log files consuming all the remaining space on the filesystem. Activating logging over the inet domain sockets will of course expose a system to risks outside of programs or individuals on the local machine.

There are a number of methods of protecting a machine:

1.

Implement kernel firewalling to limit which hosts or networks have access to the 514/UDP socket.

2.

Logging can be directed to an isolated or non-root filesystem which, if filled, will not impair the machine.

3.

The ext2 filesystem can be used which can be configured to limit a certain percentage of a filesystem to usage by root only. NOTE that this will require syslogd to be run as a non-root process. ALSO NOTE that this will prevent usage of remote logging since syslogd will be unable to bind to the 514/UDP socket.

4.

Disabling inet domain sockets will limit risk to the local machine.

5.

Use step 4 and if the problem persists and is not secondary to a rogue program/daemon get a 3.5 ft (approx. 1 meter) length of sucker rod* and have a chat with the user in question. Sucker rod def. — 3/4, 7/8 or 1in. hardened steel rod, male threaded on each end. Primary use in the oil industry in Western North Dakota and other locations to pump 'suck' oil from oil wells. Secondary uses are for the construction of cattle feed lots and for dealing with the occasional recalcitrant or belligerent individual.

## DEBUGGING
When debugging is turned on using -d option then syslogd will be very verbose by writing much of what it does on stdout. Whenever the configuration file is reread and re-parsed you'll see a tabular, corresponding to the internal data structure. This tabular consists of four fields:

number

This field contains a serial number starting by zero. This number represents the position in the internal data structure (i.e. the array). If one number is left out then there might be an error in the corresponding line in /etc/syslog.conf.

pattern

This field is tricky and represents the internal structure exactly. Every column stands for a facility (refer to syslog(3)). As you can see, there are still some facilities left free for former use, only the left most are used. Every field in a column represents the priorities (refer to syslog(3)).

action

This field describes the particular action that takes place whenever a message is received that matches the pattern. Refer to the syslog.conf(5) manpage for all possible actions.

arguments

This field shows additional arguments to the actions in the last field. For file-logging this is the filename for the logfile; for user-logging this is a list of users; for remote logging this is the hostname of the machine to log to; for console-logging this is the used console; for tty-logging this is the specified tty; wall has no additional arguments.

## FILES
/etc/syslog.conf

Configuration file for syslogd. See syslog.conf(5) for exact information.

/dev/log

The Unix domain socket to from where local syslog messages are read.

/var/run/syslogd.pid

The file containing the process id of syslogd.

## BUGS
If an error occurs in one line the whole rule is ignored.

Syslogd doesn't change the filemode of opened logfiles at any stage of process. If a file is created it is world readable. If you want to avoid this, you have to create it and change permissions on your own. This could be done in combination with rotating logfiles using the savelog(8) program that is shipped in the smail 3.x distribution. Remember that it might be a security hole if everybody is able to read auth.* messages as these might contain passwords.

## SEE ALSO
syslog.conf(5), klogd(8), logger(1), syslog(2), syslog(3), services(5), savelog(8).

## AUTHORS
The system log daemon syslogd is originally taken from BSD sources, Greg Wettstein <greg@wind.enjellic.com> performed the port to Linux, Martin Schulze <joey@infodrom.org> fixed some bugs, added several new features and took over maintenance.


package: sysstat

title: sa1(8)

text:
# sa1(8)

## NAME
sa1 - Collect and store binary data in the system activity daily data file.

## SYNOPSIS
/usr/lib64/sa/sa1 [ --boot | --rotate [ iso ] | --sleep | interval count ]

## DESCRIPTION
The sa1 command is a shell procedure variant of the sadc command and handles all of the flags and parameters of that command. The sa1 command collects and stores binary data in the current standard system activity daily data file.

The standard system activity daily data file is named saDD unless sadc's option -D is used, in which case its name is saYYYYMMDD, where YYYY stands for the current year, MM for the current month and DD for the current day. By default it is located in the /var/log/sa directory.

The interval and count parameters specify that the record should be written count times at interval seconds. If no arguments are given to sa1 then a single record is written.

The sa1 command is designed to be started automatically by the cron command.

## OPTIONS
--boot

This option tells sa1 that the sadc command should be called without specifying the interval and count parameters in order to insert a dummy record, marking the time when the counters restart from 0.

--rotate [ iso ]

Use this option to tell sa1 to insert a record of statistics to the standard saDD system activity daily data file of the previous day. This should be done shortly after midnight (on day DD+1) in order to make sure that the data file covers the whole day, including the last interval of time just before midnight. Adding the iso keyword tells sa1 to use saYYYYMMDD instead of saDD as the standard system activity daily data file name.

--sleep

This option tells sa1 that the sadc command should insert a comment indicating that the system is entering or leaving sleep mode (i.e. system suspend or hibernation).

## EXAMPLE
To collect data (including those from disks) every 10 minutes, place the following entry in your root crontab file:

0,10,20,30,40,50 * * * * /usr/lib64/sa/sa1 1 1 -S DISK

To rotate current system activity daily data file, ensuring it is complete, place the following entry in your root crontab file:

0 0 * * * /usr/lib64/sa/sa1 --rotate

## FILES
/var/log/sa/saDD

/var/log/sa/saYYYYMMDD

The standard system activity daily data files and their default location. YYYY stands for the current year, MM for the current month and DD for the current day.

## AUTHOR
Sebastien Godard (sysstat <at> orange.fr)

## SEE ALSO
sar(1), sadc(8), sa2(8), sadf(1), sysstat(5)

https://github.com/sysstat/sysstat

https://sysstat.github.io/


title: sa2(8)

text:
# sa2(8)

## NAME
sa2 - Create a report from the current standard system activity daily data file.

## SYNOPSIS
/usr/lib64/sa/sa2

## DESCRIPTION
The sa2 command is a shell procedure variant of the sar command which writes a daily report in the sarDD or the sarYYYYMMDD file, where YYYY stands for the current year, MM for the current month and DD for the current day. By default the report is saved in the /var/log/sa directory. The sa2 command will also remove reports more than one week old by default. You can however keep reports for a longer (or a shorter) period by setting the HISTORY environment variable. Read the sysstat(5) manual page for details.

The sa2 command accepts most of the flags and parameters of the sar command.

The sa2 command is designed to be started automatically by the cron command.

## EXAMPLES
To run the sa2 command daily, place the following entry in your root crontab file:

5 19 * * 1-5 /usr/lib64/sa/sa2 -A

This will generate by default a daily report called sarDD in the /var/log/sa directory, where the DD parameter is a number representing the day of the month.

## FILES
/var/log/sa/sarDD

/var/log/sa/sarYYYYMMDD

The standard system activity daily report files and their default location. YYYY stands for the current year, MM for the current month and DD for the current day.

## AUTHOR
Sebastien Godard (sysstat <at> orange.fr)

## SEE ALSO
sar(1), sadc(8), sa1(8), sadf(1), sysstat(5)

https://github.com/sysstat/sysstat

https://sysstat.github.io/


sadc

title: sadc(8)

summary: System activity data collector.

text:
# sadc(8)

## NAME
sadc - System activity data collector.

## SYNOPSIS
/usr/lib64/sa/sadc [ -C comment ] [ -D ] [ -F ] [ -f ] [ -L ] [ -V ] [ -S { keyword[,...] | ALL | XALL } ] [ interval [ count ] ] [ outfile ]

## DESCRIPTION
The sadc command samples system data a specified number of times (count) at a specified interval measured in seconds (interval). It writes in binary format to the specified outfile or to standard output. If outfile is set to -, then sadc uses the standard system activity daily data file (see below). In this case, if the file already exists, sadc will overwrite it if it is from a previous month. By default sadc collects most of the data available from the kernel. But there are also optional metrics, for which the relevant options must be explicitly passed to sadc to be collected (see option -S below).

The standard system activity daily data file is named saDD unless option -D is used, in which case its name is saYYYYMMDD, where YYYY stands for the current year, MM for the current month and DD for the current day. By default it is located in the /var/log/sa directory. Yet it is possible to specify an alternate location for it: If outfile is a directory (instead of a plain file) then it will be considered as the directory where the standard system activity daily data file will be saved.

When the count parameter is not specified, sadc writes its data endlessly. When both interval and count are not specified, and option -C is not used, a dummy record, which is used at system startup to mark the time when the counter restarts from 0, will be written. For example, one of the system startup script may write the restart mark to the daily data file by the command entry:

/usr/lib64/sa/sadc -

The sadc command is intended to be used as a backend to the sar command.

Note: The sadc command only reports on local activities.

## OPTIONS
-C comment

When neither the interval nor the count parameters are specified, this option tells sadc to write a dummy record containing the specified comment string. This comment can then be displayed with option -C of sar.

-D

Use saYYYYMMDD instead of saDD as the standard system activity daily data file name.

-F

The creation of outfile will be forced. If the file already exists and has a format unknown to sadc then it will be truncated. This may be useful for daily data files created by an older version of sadc and whose format is no longer compatible with current one.

-f

fdatasync() will be used to ensure data is written to disk. This differs from the normal operation in that a sudden system reset is less likely to result in the saDD datafiles being corrupted. However, this is at the expense of performance within the sadc process as forward progress will be blocked while data is written to underlying disk instead of just to cache.

-L

sadc will try to get an exclusive lock on the outfile before writing to it or truncating it. Failure to get the lock is fatal, except in the case of trying to write a normal (i.e. not a dummy and not a header) record to an existing file, in which case sadc will try again at the next interval. Usually, the only reason a lock would fail would be if another sadc process were also writing to the file. This can happen when cron is used to launch sadc. If the system is under heavy load, an old sadc might still be running when cron starts a new one. Without locking, this situation can result in a corrupted system activity file.

-S { keyword[,...] | ALL | XALL }

Possible keywords are DISK, INT, IPV6, POWER, SNMP, XDISK, ALL and XALL.

Specify which optional activities should be collected by sadc. Some activities are optional to prevent data files from growing too large. The DISK keyword indicates that sadc should collect data for block devices. The INT keyword indicates that sadc should collect data for system interrupts. The IPV6 keyword indicates that IPv6 statistics should be collected by sadc. The POWER keyword indicates that sadc should collect power management statistics. The SNMP keyword indicates that SNMP statistics should be collected by sadc. The ALL keyword is equivalent to specifying all the keywords above and therefore all previous activities are collected.

The XDISK keyword is an extension to the DISK one and indicates that partitions and filesystems statistics should be collected by sadc in addition to disk statistics. This option works only with kernels 2.6.25 and later. The XALL keyword is equivalent to specifying all the keywords above (including keyword extensions) and therefore all possible activities are collected.

Important note: The activities (including optional ones) saved in an existing data file prevail over those selected with option -S. As a consequence, appending data to an existing data file will result in option -S being ignored.

-V

Print version number then exit.

## ENVIRONMENT
The sadc command takes into account the following environment variable:

S_TIME_DEF_TIME

If this variable exists and its value is UTC then sadc will save its data in UTC time. sadc will also use UTC time instead of local time to determine the current daily data file located in the /var/log/sa directory.

## EXAMPLES
/usr/lib64/sa/sadc 1 10 /tmp/datafile

Write 10 records of one second intervals to the /tmp/datafile binary file.

/usr/lib64/sa/sadc -C "Backup Start" /tmp/datafile

Insert the comment "Backup Start" into the file /tmp/datafile.

## BUGS
The /proc filesystem must be mounted for the sadc command to work.

All the statistics are not necessarily available, depending on the kernel version used. sadc assumes that you are using at least a 2.6 kernel.

## FILES
/var/log/sa/saDD

/var/log/sa/saYYYYMMDD

The standard system activity daily data files and their default location. YYYY stands for the current year, MM for the current month and DD for the current day.

/proc and /sys contain various files with system statistics.

## AUTHOR
Sebastien Godard (sysstat <at> orange.fr)

## SEE ALSO
sar(1), sa1(8), sa2(8), sadf(1), sysstat(5)

https://github.com/sysstat/sysstat

https://sysstat.github.io/


kernel-install

package: systemd

title: kernel-install(8)

text:
# kernel-install(8)

## NAME
kernel-install - Add and remove kernel and initrd images to and from the boot partition

## SYNOPSIS
kernel-install [OPTIONS...] add KERNEL-VERSION KERNEL-IMAGE [INITRD-FILE...]

kernel-install [OPTIONS...] add-all

kernel-install [OPTIONS...] remove KERNEL-VERSION

kernel-install [OPTIONS...] inspect [KERNEL-VERSION] [KERNEL-IMAGE] [INITRD-FILE...]

kernel-install [OPTIONS...] list

## DESCRIPTION
kernel-install is used to install and remove kernel and initrd images [1] to and from the boot partition, referred to as $BOOT here. It will usually be one of /boot/, /efi/, or /boot/efi/, see below.

kernel-install will run the executable files ("plugins") located in the directory /usr/lib/kernel/install.d/ and the local administration directory /etc/kernel/install.d/. All files are collectively sorted and executed in lexical order, regardless of the directory in which they live. However, files with identical filenames replace each other. Files in /etc/kernel/install.d/ take precedence over files with the same name in /usr/lib/kernel/install.d/. This can be used to override a system-supplied executables with a local file if needed; a symbolic link in /etc/kernel/install.d/ with the same name as an executable in /usr/lib/kernel/install.d/, pointing to /dev/null, disables the executable entirely. Executables must have the extension ".install"; other extensions are ignored.

An executable placed in these directories should return 0 on success. It may also return 77 to cause the whole operation to terminate (executables later in lexical order will be skipped).

## COMMANDS
The following commands are understood:

add [[[KERNEL-VERSION] KERNEL-IMAGE] [INITRD-FILE ...]]

This command takes a kernel version string and a path to a kernel image file as arguments. If the former is omitted, specified as an empty string or as "-" it defaults to the current kernel version, i.e. the same string uname -r returns. If the latter is omitted, specified as an empty string or as "-" defaults to /usr/lib/modules/KERNEL_VERSION/vmlinuz. Optionally, one or more initrd images may be specified as well (note that plugins might generate additional ones). The executable files from /usr/lib/kernel/install.d/*.install and /etc/kernel/install.d/*.install (i.e. the plugins) are called with the following arguments:

```
add KERNEL-VERSION $BOOT/ENTRY-TOKEN/KERNEL-VERSION/ KERNEL-IMAGE \

          [INITRD-FILE ...]
```

The third argument directly refers to the path where to place kernel images, initrd images and other resources for Boot Loader Specification[2] Type #1 entries (the "entry directory"). If other boot loader schemes are used the parameter may be ignored.

The ENTRY-TOKEN string is typically the machine ID and is supposed to identify the local installation on the system. For details see below.

Two default plugins execute the following operations in this case:

•kernel-install creates $BOOT/ENTRY-TOKEN/KERNEL-VERSION, if enabled (see $KERNEL_INSTALL_LAYOUT).

•50-depmod.install runs depmod(8) for the KERNEL-VERSION.

•90-loaderentry.install copies KERNEL-IMAGE to $BOOT/ENTRY-TOKEN/KERNEL-VERSION/linux. If INITRD-FILEs are provided, it also copies them to $BOOT/ENTRY-TOKEN/KERNEL_VERSION/INITRD-FILE. This can also be used to prepend microcode before the actual initrd. It also creates a boot loader entry according to the Boot Loader Specification[2] (Type #1) in $BOOT/loader/entries/ENTRY-TOKEN-KERNEL-VERSION.conf. The title of the entry is the PRETTY_NAME parameter specified in /etc/os-release or /usr/lib/os-release (if the former is missing), or "Linux KERNEL-VERSION", if unset. If $KERNEL_INSTALL_LAYOUT is not "bls", this plugin does nothing.

•90-uki-copy.install copies a file uki.efi from $KERNEL_INSTALL_STAGING_AREA or if it does not exist the KERNEL-IMAGE argument, only if it has a ".efi" extension, to $BOOT/EFI/Linux/ENTRY-TOKEN-KERNEL-VERSION.efi. If $KERNEL_INSTALL_LAYOUT is not "uki", this plugin does nothing.

Added in version 198.

add-all

This is the same as add (see above), but invokes the operation iteratively for every installed kernel in /usr/lib/modules/. This operation is only supported on systems where the kernel image is installed in /usr/lib/modules/KERNEL-VERSION/vmlinuz. Added in version 255.

remove KERNEL-VERSION

This command expects a kernel version string as single argument. The executable files from /usr/lib/kernel/install.d/*.install and /etc/kernel/install.d/*.install (i.e. the plugins) are called with the following arguments:

```
remove KERNEL-VERSION $BOOT/ENTRY-TOKEN/KERNEL-VERSION/
```

Afterwards, kernel-install removes the entry directory $BOOT/ENTRY-TOKEN/KERNEL-VERSION/ and its contents, if it exists.

Two default plugins execute the following operations in this case:

•50-depmod.install removes the files generated by depmod for this kernel again.

•90-loaderentry.install removes the file $BOOT/loader/entries/ENTRY-TOKEN-KERNEL-VERSION.conf.

•90-uki-copy.install removes the file $BOOT/EFI/Linux/ENTRY-TOKEN-KERNEL-VERSION.efi.

Added in version 198.

inspect [[[KERNEL-VERSION] KERNEL-IMAGE] [INITRD-FILE ...]]

Takes the same parameters as add. Shows the various paths and parameters configured or auto-detected. In particular shows the values of the various $KERNEL_INSTALL_* environment variables listed below, as they would be passed to plugins. The --json option can be used to get the output of this verb as a JSON object.

Added in version 251.

list

Shows the various installed kernels. This enumerates the subdirectories of /usr/lib/modules/, and shows whether a kernel image is installed there. Added in version 255.

## COMPATIBILITY WITH THE KERNEL BUILD SYSTEM
installkernel [OPTIONS...] VERSION VMLINUZ [MAP] [INSTALLATION-DIR]

When invoked as installkernel, this program accepts arguments as specified by the kernel build system's make install command. The VERSION and VMLINUZ parameters specify the kernel version and the kernel binary. The other two parameters (MAP and INSTALLATION-DIR) are currently ignored.

## THE $BOOT PARTITION
The partition where the kernels and Boot Loader Specification[2] snippets are located is called $BOOT. kernel-install determines the location of this partition by checking /efi/, /boot/, and /boot/efi/ in turn. The first location where $BOOT/loader/entries/ or $BOOT/ENTRY-TOKEN/ exists is used.

## OPTIONS
The following options are understood:

--esp-path=

Path to the EFI System Partition (ESP). If not specified, /efi/, /boot/, and /boot/efi/ are checked in turn. It is recommended to mount the ESP to /efi/, if possible.

--boot-path=

Path to the Extended Boot Loader partition, as defined in the Boot Loader Specification[2]. If not specified, /boot/ is checked. It is recommended to mount the Extended Boot Loader partition to /boot/, if possible.

--make-entry-directory=yes|no|auto

Controls creation and deletion of the Boot Loader Specification[2] Type #1 entry directory on the file system containing resources such as kernel and initrd images during add and remove, respectively. The directory is named after the entry token, and is placed immediately below the boot root directory. When "auto", the directory is created or removed only when the install layout is "bls". Defaults to "auto". Added in version 254.

--entry-token=

Controls how to name and identify boot loader entries for this kernel installation or deletion. Takes one of "auto", "machine-id", "os-id", "os-image-id", or an arbitrary string prefixed by "literal:" as argument. If set to machine-id the entries are named after the machine ID of the running system (e.g. "b0e793a9baf14b5fa13ecbe84ff637ac"). See machine-id(5) for details about the machine ID concept and file.

If set to os-id the entries are named after the OS ID of the running system, i.e. the ID= field of os-release(5) (e.g. "fedora"). Similarly, if set to os-image-id the entries are named after the OS image ID of the running system, i.e. the IMAGE_ID= field of os-release (e.g. "vendorx-cashier-system").

If set to auto (the default), the /etc/kernel/entry-token (or $KERNEL_INSTALL_CONF_ROOT/entry-token) file will be read if it exists, and the stored value used. Otherwise, if the local machine ID is initialized, it is used. Otherwise, IMAGE_ID= from os-release will be used, if set. Otherwise, ID= from os-release will be used, if set. Otherwise, a randomly generated machine ID is used.

Using the machine ID for naming the entries is generally preferable, however there are cases where using the other identifiers is a good option. Specifically: if the identification data that the machine ID entails shall not be stored on the (unencrypted) $BOOT_ROOT partition, or if the ID shall be generated on first boot and is not known when the entries are prepared. Note that using the machine ID has the benefit that multiple parallel installations of the same OS can coexist on the same medium, and they can update their boot loader entries independently. When using another identifier (such as the OS ID or the OS image ID), parallel installations of the same OS would try to use the same entry name. To support parallel installations, the installer must use a different entry token when adding a second installation.

Added in version 254.

-v, --verbose

Output additional information about operations being performed. Added in version 242.

--root=root

Takes a directory path as an argument. All paths will be prefixed with the given alternate root path, including config search paths. This is useful to operate on a system image mounted to the specified directory instead of the host system itself. Added in version 255.

--image=image

Takes a path to a disk image file or block device node. If specified, all operations are applied to the file system in the indicated disk image. This option is similar to --root=, but operates on file systems stored in disk images or block devices. The disk image should either contain just a file system or a set of file systems within a GPT partition table, following the Discoverable Partitions Specification[3]. For further information on supported disk images, see systemd-nspawn(1)'s switch of the same name. Added in version 255.

-h, --help

Print a short help text and exit.

--version

Print a short version string and exit.

--no-pager

Do not pipe output into a pager.

--json=MODE

Shows output formatted as JSON. Expects one of "short" (for the shortest possible output without any redundant whitespace or line breaks), "pretty" (for a pretty version of the same, with indentation and line breaks) or "off" (to turn off JSON output, the default).

--image-policy=policy

Takes an image policy string as argument, as per systemd.image-policy(7). The policy is enforced when operating on the disk image specified via --image=, see above. If not specified, defaults to the "*" policy, i.e. all recognized file systems in the image are used.

--no-legend

Do not print the legend, i.e. column headers and the footer with hints.

## ENVIRONMENT VARIABLES

### Environment variables exported for plugins
If --verbose is used, $KERNEL_INSTALL_VERBOSE=1 will be exported for plugins. They may output additional logs in this case.

$KERNEL_INSTALL_IMAGE_TYPE=uki|pe|unknown is set for the plugins to specify the type of the kernel image.

uki

Unified kernel image. Added in version 254.

pe

PE binary. Added in version 254.

unknown

Unknown type. Added in version 254.

$KERNEL_INSTALL_MACHINE_ID is set for the plugins to the desired machine-id to use. It's always a 128-bit ID. Normally it is read from /etc/machine-id, but it can also be overridden via $MACHINE_ID (see below). If not specified via these methods, a fallback value will generated by kernel-install and used only for a single invocation.

$KERNEL_INSTALL_ENTRY_TOKEN is set for the plugins to the desired entry "token" to use. It's an identifier that shall be used to identify the local installation, and is often the machine ID, i.e. same as $KERNEL_INSTALL_MACHINE_ID, but might also be a different type of identifier, for example a fixed string or the ID=, IMAGE_ID= values from /etc/os-release. The string passed here will be used to name Boot Loader Specification entries, or the directories the kernel image and initial RAM disk images are placed into.

Note that while $KERNEL_INSTALL_ENTRY_TOKEN and $KERNEL_INSTALL_MACHINE_ID are often set to the same value, the latter is guaranteed to be a valid 32 character ID in lowercase hexadecimals while the former can be any short string. The entry token to use is read from /etc/kernel/entry-token, if it exists. Otherwise, a few possible candidates below $BOOT are checked for Boot Loader Specification Type 1 entry directories, and if found the entry token is derived from that. If that is not successful, $KERNEL_INSTALL_MACHINE_ID is used as fallback.

$KERNEL_INSTALL_BOOT_ROOT is set for the plugins to the absolute path of the root directory (mount point, usually) of the hierarchy where boot loader entries, kernel images, and associated resources should be placed. This usually is the path where the XBOOTLDR partition or the ESP (EFI System Partition) are mounted, and also conceptually referred to as $BOOT. Can be overridden by setting $BOOT_ROOT (see below).

$KERNEL_INSTALL_LAYOUT=auto|bls|uki|other|... is set for the plugins to specify the installation layout. Additional layout names may be defined by convention. If a plugin uses a special layout, it is encouraged to declare its own layout name and configure layout= in install.conf upon initial installation. The following values are currently understood:

bls

Standard Boot Loader Specification[2] Type #1 layout, compatible with systemd-boot(7): entries in $BOOT/loader/entries/ENTRY-TOKEN-KERNEL-VERSION[+TRIES].conf, kernel and initrds under $BOOT/ENTRY-TOKEN/KERNEL-VERSION/ Implemented by 90-loaderentry.install.

Added in version 250.

uki

Standard Boot Loader Specification[2] Type #2 layout, compatible with systemd-boot(7): unified kernel images under $BOOT/EFI/Linux as $BOOT/EFI/Linux/ENTRY-TOKEN-KERNEL-VERSION[+TRIES].efi. Implemented by 90-uki-copy.install.

Added in version 253.

other

Some other layout not understood natively by kernel-install. Added in version 250.

auto

Pick the layout automatically. If the kernel is a UKI set layout to uki. If not default to bls if $BOOT/loader/entries.srel with content "type1" or $BOOT/ENTRY-TOKEN exists, or other otherwise. Leaving layout blank has the same effect. This is the default.

Added in version 254.

$KERNEL_INSTALL_INITRD_GENERATOR and $KERNEL_INSTALL_UKI_GENERATOR are set for plugins to select the initrd and/or UKI generator. This may be configured as initrd_generator= and uki_generator= in install.conf, see below.

$KERNEL_INSTALL_STAGING_AREA is set for plugins to a path to a directory. Plugins may drop files in that directory, and they will be installed as part of the loader entry, based on the file name and extension: Files named initrd* will be installed as INITRD-FILEs, and files named microcode* will be prepended before INITRD-FILEs.

### Environment variables understood by kernel-install
$KERNEL_INSTALL_CONF_ROOT can be set to override the location of the configuration files read by kernel-install. When set, install.conf, entry-token, and other files will be read from this directory only. Note that this path is relative to the host, and in particular symlinks in this directory are resolved relative to the host, even if --root=root is used. This means that it is generally not correct to use this variable to specify a directory underneath root if symlinks are used there.

$KERNEL_INSTALL_PLUGINS can be set to override the list of plugins executed by kernel-install. The argument is a whitespace-separated list of paths. "KERNEL_INSTALL_PLUGINS=:" may be used to prevent any plugins from running.

$MACHINE_ID can be set for kernel-install to override $KERNEL_INSTALL_MACHINE_ID, the machine ID.

$BOOT_ROOT can be set for kernel-install to override $KERNEL_INSTALL_BOOT_ROOT, the installation location for boot entries.

The last two variables may also be set in install.conf. Variables set in the environment take precedence over the values specified in the config file.

## EXIT STATUS
If every executable returns 0 or 77, 0 is returned, and a non-zero failure code otherwise.

## FILES
/etc/kernel/install.d/*.install, /usr/lib/kernel/install.d/*.install

Drop-in files which are executed by kernel-install. Added in version 198.

/etc/kernel/cmdline, /usr/lib/kernel/cmdline, /proc/cmdline

Specifies the kernel command line to use. The first of the files that is found will be used. $KERNEL_INSTALL_CONF_ROOT may be used to override the search path; see below for details. Added in version 198.

/etc/kernel/devicetree, /usr/lib/kernel/devicetree

Specifies the partial path to the file containing the device tree blob to install with the kernel and use at boot. The first of the files that is found will be used. $KERNEL_INSTALL_CONF_ROOT may be used to override the search path; see below for details. The devicetree file contains a path, and this path specifies a location relative to the kernel install tree. A set of locations is checked, including in particular /usr/lib/modules/KERNEL_VERSION/dtb/, which is the recommended location to place the dtb files under. For example, with "broadcom/bcm2711-rpi-4-b.dtb" in the devicetree file, the device tree blob for the Raspberry Pi 4 Model B would be installed, and the actual file would be /usr/lib/modules/KERNEL_VERSION/dtb/broadcom/bcm2711-rpi-4-b.dtb.

Added in version 255.

/etc/kernel/tries

Read by 90-loaderentry.install and 90-uki-copy.install. If this file exists, a numeric value is read from it and the naming of the generated entry file or UKI is altered to include it as $BOOT/loader/entries/ENTRY-TOKEN-KERNEL-VERSION+TRIES.conf or $BOOT/EFI/Linux/ENTRY-TOKEN-KERNEL-VERSION+TRIES.efi, respectively. This is useful for boot loaders such as systemd-boot(7) which implement boot attempt counting with a counter embedded in the entry file name. $KERNEL_INSTALL_CONF_ROOT may be used to override the search path; see below for details. Added in version 240.

/etc/kernel/entry-token

If this file exists it is read and used as "entry token" for this system, i.e. is used for naming Boot Loader Specification entries. See $KERNEL_INSTALL_ENTRY_TOKEN above for details. $KERNEL_INSTALL_CONF_ROOT may be used to override the search path; see below for details. Added in version 251.

/etc/machine-id

The content of this file specifies the machine identification MACHINE-ID. Added in version 198.

/etc/os-release, /usr/lib/os-release

Read by 90-loaderentry.install. If available, PRETTY_NAME= is read from these files and used as the title of the boot menu entry. Otherwise, "Linux KERNEL-VERSION" will be used. Added in version 198.

/etc/kernel/install.conf, /run/kernel/install.conf, /usr/local/lib/kernel/install.conf, /usr/lib/kernel/install.conf, /etc/kernel/install.conf.d/*.conf, /run/kernel/install.conf.d/*.conf, /usr/local/lib/kernel/install.conf.d/*.conf, /usr/lib/kernel/install.conf.d/*.conf

Configuration file with options for kernel-install, as a series of KEY=VALUE assignments, compatible with shell syntax, following the same rules as described in os-release(5). The first of the files that is found will be used. $KERNEL_INSTALL_CONF_ROOT may be used to override the search path; see below for details. Drop-in files may also be used to extend the configuration with overrides, see systemd.unit(5). Currently, the following keys are supported: MACHINE_ID=, BOOT_ROOT=, layout=, initrd_generator=, uki_generator=. See the Environment variables section above for details.

Added in version 250.

/etc/kernel/uki.conf

Ini-style configuration file for ukify(1) which is only effective when $KERNEL_INSTALL_LAYOUT or layout= in install.conf is set to uki and $KERNEL_INSTALL_UKI_GENERATOR or uki_generator= in install.conf is set to ukify, or is unset. $KERNEL_INSTALL_CONF_ROOT may be used to override the search path; see below for details. Added in version 255.

/usr/lib/modules/KERNEL-VERSION/

Location for installed kernel modules and other kernel related resources. For each locally installed kernel a directory named after the kernel version (uname -r) is kept. Added in version 255.

/usr/lib/modules/KERNEL-VERSION/vmlinuz

Location for installed kernel images. This is the recommended location for OS package managers to install kernel images into (as applicable), from which kernel-install add then copies it into the final boot partition. Added in version 255.

For various cases listed above, if the $KERNEL_INSTALL_CONF_ROOT environment variable is set, it will override the search path. The files will be loaded only from the directory specified by the environment variable. When the variable is not set, the listed paths are tried in turn, and the first file that exists is used.

## SEE ALSO
machine-id(5), os-release(5), depmod(8), systemd-boot(7), ukify(1), Boot Loader Specification[2]

## NOTES
1.

Nowadays actually CPIO archives used as an "initramfs", rather than "initrd". See bootup(7) for an explanation.

2.

Boot Loader Specification

https://uapi-group.org/specifications/specs/boot_loader_specification

3.

Discoverable Partitions Specification

https://uapi-group.org/specifications/specs/discoverable_partitions_specification


poweroff

title: poweroff(8)

summary: Power off, reboot, or halt the machine

text:
# poweroff(8)

## NAME
poweroff, reboot, halt - Power off, reboot, or halt the machine

## SYNOPSIS
poweroff [OPTIONS...]

reboot [OPTIONS...]

halt [OPTIONS...]

## DESCRIPTION
poweroff, reboot, and halt may be used to power off, reboot, or halt the machine. All three commands take the same options.

## OPTIONS
The following options are understood:

--help

Print a short help text and exit. Added in version 253.

--halt

Halt the machine, regardless of which one of the three commands is invoked. Added in version 253.

-p, --poweroff

Power off the machine, when either halt or poweroff is invoked. This option is ignored when reboot is invoked. Added in version 253.

--reboot

Reboot the machine, regardless of which one of the three commands is invoked. Added in version 253.

-f, --force

Force immediate power-off, halt, or reboot. If specified, the command does not contact the init system. In most cases, filesystems are not properly unmounted before shutdown. For example, the command reboot -f is mostly equivalent to systemctl reboot -ff, instead of systemctl reboot -f. Added in version 253.

-w, --wtmp-only

Only write wtmp shutdown entry, do not actually power off, reboot, or halt. Added in version 253.

-d, --no-wtmp

Do not write wtmp shutdown entry. Added in version 253.

-n, --no-sync

Do not sync hard disks/storage media before power-off, reboot, or halt. Added in version 253.

--no-wall

Do not send wall message before power-off, reboot, or halt. Added in version 253.

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

## NOTES
These commands are implemented in a way that preserves basic compatibility with the original SysV commands. systemctl(1) verbs poweroff, reboot, halt provide the same functionality with some additional features.

Note that on many SysV systems halt used to be synonymous to poweroff, i.e. both commands would equally result in powering the machine off. systemd is more accurate here, and halt results in halting the machine only (leaving power on), and poweroff is required to actually power it off.

## SEE ALSO
systemd(1), systemctl(1), shutdown(8), wall(1)


runlevel

title: runlevel(8)

text:
# runlevel(8)

## NAME
runlevel - Print previous and current SysV runlevel

## SYNOPSIS
runlevel [options...]

## OVERVIEW
"Runlevels" are an obsolete way to start and stop groups of services used in SysV init. systemd provides a compatibility layer that maps runlevels to targets, and associated binaries like runlevel. Nevertheless, only one runlevel can be "active" at a given time, while systemd can activate multiple targets concurrently, so the mapping to runlevels is confusing and only approximate. Runlevels should not be used in new code, and are mostly useful as a shorthand way to refer the matching systemd targets in kernel boot parameters.

Table 1. Mapping between runlevels and systemd targets

Runlevel

Target

0

poweroff.target

1

rescue.target

2, 3, 4

multi-user.target

5

graphical.target

6

reboot.target

## DESCRIPTION
runlevel

prints the previous and current SysV runlevel if they are known.

The two runlevel characters are separated by a single space character. If a runlevel cannot be determined, N is printed instead. If neither can be determined, the word "unknown" is printed.

Unless overridden in the environment, this will check the utmp database for recent runlevel changes.

## OPTIONS
The following option is understood:

--help

Print a short help text and exit.

## EXIT STATUS
If one or both runlevels could be determined, 0 is returned, a non-zero failure code otherwise.

## ENVIRONMENT
$RUNLEVEL

If $RUNLEVEL is set, runlevel will print this value as current runlevel and ignore utmp.

$PREVLEVEL

If $PREVLEVEL is set, runlevel will print this value as previous runlevel and ignore utmp.

## FILES
/run/utmp

The utmp database runlevel reads the previous and current runlevel from. Added in version 237.

## SEE ALSO
systemd(1), systemd.target(5), systemctl(1)


shutdown

title: shutdown(8)

summary: Halt, power off or reboot the machine

text:
# shutdown(8)

## NAME
shutdown - Halt, power off or reboot the machine

## SYNOPSIS
shutdown [OPTIONS...] [TIME] [WALL...]

## DESCRIPTION
shutdown may be used to halt, power off, or reboot the machine.

The first argument may be a time string (which is usually "now"). Optionally, this may be followed by a wall message to be sent to all logged-in users before going down.

The time string may either be in the format "hh:mm" for hour/minutes specifying the time to execute the shutdown at, specified in 24h clock format. Alternatively it may be in the syntax "+m" referring to the specified number of minutes m from now. "now" is an alias for "+0", i.e. for triggering an immediate shutdown. If no time argument is specified, "+1" is implied.

Note that to specify a wall message you must specify a time argument, too.

If the time argument is used, 5 minutes before the system goes down the /run/nologin file is created to ensure that further logins shall not be allowed.

## OPTIONS
The following options are understood:

--help

Print a short help text and exit.

-H, --halt

Halt the machine.

-P, --poweroff

Power the machine off (the default).

-r, --reboot

Reboot the machine.

-h

The same as --poweroff, but does not override the action to take if it is "halt". E.g. shutdown --reboot -h means "poweroff", but shutdown --halt -h means "halt".

-k

Do not halt, power off, or reboot, but just write the wall message.

--no-wall

Do not send wall message before halt, power off, or reboot.

-c

Cancel a pending shutdown. This may be used to cancel the effect of an invocation of shutdown with a time argument that is not "+0" or "now".

--show

Show a pending shutdown action and time if there is any. Added in version 250.

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

## COMPATIBILITY
The shutdown command in previous init systems (including sysvinit) defaulted to single-user mode instead of powering off the machine. To change into single-user mode, use systemctl rescue instead.

## SEE ALSO
systemd(1), systemctl(1), halt(8), wall(1)


systemd-ask-password-console.service

title: systemd-ask-password-console.service(8)

text:
# systemd-ask-password-console.service(8)

## NAME
systemd-ask-password-console.service, systemd-ask-password-console.path, systemd-ask-password-wall.service, systemd-ask-password-wall.path - Query the user for system passwords on the console and via wall

## SYNOPSIS
systemd-ask-password-console.service

systemd-ask-password-console.path

systemd-ask-password-wall.service

systemd-ask-password-wall.path

## DESCRIPTION
systemd-ask-password-console.service is a system service that queries the user for system passwords (such as hard disk encryption keys and SSL certificate passphrases) on the console. It is intended to be used during boot to ensure proper handling of passwords necessary for boot. systemd-ask-password-wall.service is a system service that informs all logged in users for system passwords via wall(1). It is intended to be used after boot to ensure that users are properly notified.

See the developer documentation[1] for more information about the system password logic.

Note that these services invoke systemd-tty-ask-password-agent(1) with either the --watch --console or --watch --wall command line parameters.

## SEE ALSO
systemd(1), systemd-tty-ask-password-agent(1), wall(1)

## NOTES
1.

developer documentation

https://systemd.io/PASSWORD_AGENTS/


systemd-backlight@.service

title: systemd-backlight@.service(8)

text:
# systemd-backlight@.service(8)

## NAME
systemd-backlight@.service, systemd-backlight - Load and save the display backlight brightness at boot and shutdown

## SYNOPSIS
systemd-backlight@.service

/usr/lib/systemd/systemd-backlight save [backlight|leds]:DEVICE

/usr/lib/systemd/systemd-backlight load [backlight|leds]:DEVICE

## DESCRIPTION
systemd-backlight@.service is a service that restores the brightness of a display backlight or LED (e.g. keyboard backlight) device at early boot, and saves it at shutdown. The brightness is stored in /var/lib/systemd/backlight/.

On restoring brightness of a display backlight device, systemd-backlight reads ID_BACKLIGHT_CLAMP udev property, that takes a boolean value or a percentage (needs to be suffixed with "%", e.g. "30%"). When a percentage is specified, the saved brightness is clamped to a value of at least 1 or the specified percentage of the maximum brightness, whichever is greater. When unset or set to true, the brightness is clamped in the same way with percentage 5%. When false, the saved brightness will not be clamped, and loaded as is.

On restoring brightness of a LED device, systemd-backlight reads ID_LEDS_CLAMP udev property, that also takes a boolean value or a percentage. When a percentage is specified, the saved brightness is clamped to the specified percentage of the maximum brightness. When set to true, the brightness is clamped in the same way with percentage 5%. When unset or set to false, the saved brightness will not be clamped, and loaded as is.

## KERNEL COMMAND LINE
systemd-backlight understands the following kernel command line parameter:

systemd.restore_state=

Takes a boolean argument. Defaults to "1". If "0", does not restore the backlight settings on boot. However, settings will still be stored on shutdown. Added in version 209.

## SEE ALSO
systemd(1)