mysqld

package: MySQL-server

title: mysqld(8)

summary: the MySQL server

text:
# mysqld(8)

## NAME
mysqld - the MySQL server

## SYNOPSIS
mysqld [options]

## DESCRIPTION
mysqld, also known as MySQL Server, is a single multithreaded program that does most of the work in a MySQL installation. It does not spawn additional processes. MySQL Server manages access to the MySQL data directory that contains databases and tables. The data directory is also the default location for other information such as log files and status files.

Note

Some installation packages contain a debugging version of the server named mysqld-debug. Invoke this version instead of mysqld for debugging support, memory allocation checking, and trace file support (see Section 7.9.1.2, “Creating Trace Files”).

When MySQL server starts, it listens for network connections from client programs and manages access to databases on behalf of those clients.

The mysqld program has many options that can be specified at startup. For a complete list of options, run this command:

```
mysqld --verbose --help
```

MySQL Server also has a set of system variables that affect its operation as it runs. System variables can be set at server startup, and many of them can be changed at runtime to effect dynamic server reconfiguration. MySQL Server also has a set of status variables that provide information about its operation. You can monitor these status variables to access runtime performance characteristics.

For a full description of MySQL Server command options, system variables, and status variables, see Section 7.1, “The MySQL Server”. For information about installing MySQL and setting up the initial configuration, see Chapter 2, Installing MySQL.

## COPYRIGHT
Copyright © 1997, 2024, Oracle and/or its affiliates.

This documentation is free software; you can redistribute it and/or modify it only under the terms of the GNU General Public License as published by the Free Software Foundation; version 2 of the License.

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

You should have received a copy of the GNU General Public License along with the program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA or see http://www.gnu.org/licenses/.

## SEE ALSO
For more information, please refer to the MySQL Reference Manual, which may already be installed locally and which is also available online at http://dev.mysql.com/doc/.

## AUTHOR
Oracle Corporation (http://dev.mysql.com/).


nm-cloud-setup

package: NetworkManager-cloud-setup

title: nm-cloud-setup(8)

text:
# nm-cloud-setup(8)

## NAME
nm-cloud-setup - Overview of Automatic Network Configuration in Cloud

## OVERVIEW
When running a virtual machine in a public cloud environment, it is desirable to automatically configure the network of that VM. In simple setups, the VM only has one network interface and the public cloud supports automatic configuration via DHCP, DHCP6 or IPv6 autoconf. However, the virtual machine might have multiple network interfaces, or multiple IP addresses and IP subnets on one interface which cannot be configured via DHCP. Also, the administrator may reconfigure the network while the machine is running. NetworkManager's nm-cloud-setup is a tool that automatically picks up such configuration in cloud environments and updates the network configuration of the host.

Multiple cloud providers are supported. See the section called “SUPPORTED CLOUD PROVIDERS”.

## USE
The goal of nm-cloud-setup is to be configuration-less and work automatically. All you need is to opt-in to the desired cloud providers (see the section called “ENVIRONMENT VARIABLES”) and run /usr/libexec/nm-cloud-setup.

Usually this is done by enabling the nm-cloud-setup.service systemd service and let it run periodically. For that there is both a nm-cloud-setup.timer systemd timer and a NetworkManager dispatcher script.

## DETAILS
nm-cloud-setup configures the network by fetching the configuration from the well-known meta data server of the cloud provider. That means, it already needs the network configured to the point where it can reach the meta data server. Commonly that means, that a simple connection profile is activated that possibly uses DHCP to get the primary IP address. NetworkManager will create such a profile for ethernet devices automatically if it is not configured otherwise via "no-auto-default" setting in NetworkManager.conf. One possible alternative may be to create such an initial profile with nmcli device connect "$DEVICE" or nmcli connection add type ethernet ....

By setting the user-data org.freedesktop.nm-cloud-setup.skip=yes on the profile, nm-cloud-setup will skip the device.

nm-cloud-setup modifies the run time configuration akin to nmcli device modify. With this approach, the configuration is not persisted and only preserved until the device disconnects.

### /usr/libexec/nm-cloud-setup
The binary /usr/libexec/nm-cloud-setup does most of the work. It supports no command line arguments but can be configured via environment variables. See the section called “ENVIRONMENT VARIABLES” for the supported environment variables.

By default, all cloud providers are disabled unless you opt-in by enabling one or several providers. If cloud providers are enabled, the program tries to fetch the host's configuration from a meta data server of the cloud via HTTP. If configuration could be not fetched, no cloud provider are detected and the program quits. If host configuration is obtained, the corresponding cloud provider is successfully detected. Then the network of the host will be configured.

It is intended to re-run nm-cloud-setup every time when the configuration (maybe) changes. The tool is idempotent, so it should be OK to also run it more often than necessary. You could run /usr/libexec/nm-cloud-setup directly. However it may be preferable to restart the nm-cloud-setup systemd service instead or use the timer or dispatcher script to run it periodically (see below).

### nm-cloud-setup.service systemd unit
Usually /usr/libexec/nm-cloud-setup is not run directly, but only by systemctl restart nm-cloud-setup.service. This ensures that the tool only runs once at any time. It also allows to integrate with the nm-cloud-setup systemd timer, and to enable/disable the service via systemd.

As you need to set environment variable to configure nm-cloud-setup binary, you can do so via systemd override files. Try systemctl edit nm-cloud-setup.service.

### nm-cloud-setup.timer systemd timer
/usr/libexec/nm-cloud-setup is intended to run whenever an update is necessary. For example, during boot when when changing the network configuration of the virtual machine via the cloud provider.

One way to do this, is by enabling the nm-cloud-setup.timer systemd timer with systemctl enable --now nm-cloud-setup.timer.

### /usr/lib/NetworkManager/dispatcher.d/90-nm-cloud-setup.sh
There is also a NetworkManager dispatcher script that will run for example when an interface is activated by NetworkManager. Together with the nm-cloud-setup.timer systemd timer this script is to automatically pick up changes to the network.

The dispatcher script will do nothing, unless the systemd service is enabled. To use the dispatcher script you should therefor run systemctl enable nm-cloud-setup.service once.

## ENVIRONMENT VARIABLES
The following environment variables are used to configure /usr/libexec/nm-cloud-setup. You may want to configure them with a drop-in for the systemd service. For example by calling systemctl edit nm-cloud-setup.service and configuring [Service] Environment=, as described in systemd.exec(5) manual.

•NM_CLOUD_SETUP_LOG: control the logging verbosity. Set it to one of TRACE, DEBUG, INFO, WARN, ERR or OFF. The program will print message on stdout and the default level is WARN. When run as systemd service, the log will be collected by journald can can be seen with journalctl.

•NM_CLOUD_SETUP_AZURE: boolean, whether Microsoft Azure support is enabled. Defaults to no.

•NM_CLOUD_SETUP_EC2: boolean, whether Amazon EC2 (AWS) support is enabled. Defaults to no.

•NM_CLOUD_SETUP_GCP: boolean, whether Google GCP support is enabled. Defaults to no.

•NM_CLOUD_SETUP_ALIYUN: boolean, whether Alibaba Cloud (Aliyun) support is enabled. Defaults to no.

•NM_CLOUD_SETUP_OCI: boolean, whether Oracle Cloud (OCI) support is enabled. Defaults to no.

## DEBUGGING
Enable debug logging by setting NM_CLOUD_SETUP_LOG environment variable to TRACE.

In the common case where nm-cloud-setup is running as systemd service, this can be done via systemctl edit nm-cloud-setup.service and add Environment=NM_CLOUD_SETUP_LOG=TRACE to the [Service] section. Afterwards, the log can be found in syslog via journalctl. You may also want to enable debug logging in NetworkManager as descibed in the DEBUGGING section in NetworkManager(5) manual. When sharing logs, it's best to share complete logs and not preemptively filter for NetworkManager or nm-cloud-setup logs.

## EXAMPLE SETUP FOR CONFIGURING AND PREDEPLOYING NM-CLOUD-SETUP
As detailed before, nm-cloud-setup needs to be explicitly enabled. As it runs as a systemd service and timer, that basically means to enable and configure those. This can be done by dropping the correct files and symlinks to disk.

The following example enables nm-cloud-setup for Amazon EC2 cloud:

```
dnf install -y NetworkManager-cloud-setup
mkdir -p /etc/systemd/system/nm-cloud-setup.service.d
cat > /etc/systemd/system/nm-cloud-setup.service.d/10-enable-ec2.conf << EOF
[Service]
Environment=NM_CLOUD_SETUP_EC2=yes
EOF
# systemctl enable nm-cloud-setup.service
mkdir -p /etc/systemd/system/NetworkManager.service.wants/
ln -s /usr/lib/systemd/system/nm-cloud-setup.service /etc/systemd/system/NetworkManager.service.wants/nm-cloud-setup.service
# systemctl enable nm-cloud-setup.timer
mkdir -p /etc/systemd/system/timers.target.wants/
ln -s /etc/systemd/system/timers.target.wants/nm-cloud-setup.timer /usr/lib/systemd/system/nm-cloud-setup.timer
# systemctl daemon-reload

```

## SUPPORTED CLOUD PROVIDERS

### Amazon EC2 (AWS)
For AWS, the tools tries to fetch configuration from http://169.254.169.254/. Currently, it only configures IPv4 and does nothing about IPv6. It will do the following.

•First fetch http://169.254.169.254/latest/meta-data/ to determine whether the expected API is present. This determines whether EC2 environment is detected and whether to proceed to configure the host using EC2 meta data.

•Fetch http://169.254.169.254/2018-09-24/meta-data/network/interfaces/macs/ to get the list of available interface. Interfaces are identified by their MAC address.

•Then for each interface fetch http://169.254.169.254/2018-09-24/meta-data/network/interfaces/macs/$MAC/subnet-ipv4-cidr-block and http://169.254.169.254/2018-09-24/meta-data/network/interfaces/macs/$MAC/local-ipv4s. Thereby we get a list of local IPv4 addresses and one CIDR subnet block.

•Then nm-cloud-setup iterates over all interfaces for which it could fetch IP configuration. If no ethernet device for the respective MAC address is found, it is skipped. Also, if the device is currently not activated in NetworkManager or if the currently activated profile has a user-data org.freedesktop.nm-cloud-setup.skip=yes, it is skipped. If only one interface and one address is configured, then the tool does nothing and leaves the automatic configuration that was obtained via DHCP.

Otherwise, the tool will change the runtime configuration of the device.

•Add static IPv4 addresses for all the configured addresses from local-ipv4s with prefix length according to subnet-ipv4-cidr-block. For example, we might have here 2 IP addresses like "172.16.5.3/24,172.16.5.4/24".

•Choose a route table 30400 + the index of the interface and add a default route 0.0.0.0/0. The gateway is the first IP address in the CIDR subnet block. For example, we might get a route "0.0.0.0/0 172.16.5.1 10 table=30400". Also choose a route table 30200 + the interface index. This contains a direct routes to the subnets of this interface.

•Finally, add a policy routing rule for each address. For example "priority 30200 from 172.16.5.3/32 table 30200, priority 30200 from 172.16.5.4/32 table 30200". and "priority 30400 from 172.16.5.3/32 table 30400, priority 30400 from 172.16.5.4/32 table 30400" The 30200+ rules select the table to reach the subnet directly, while the 30400+ rules use the default route. Also add a rule "priority 30350 table main suppress_prefixlength 0". This has a priority between the two previous rules and causes a lookup of routes in the main table while ignoring the default route. The purpose of this is so that other specific routes in the main table are honored over the default route in table 30400+.

With above example, this roughly corresponds for interface eth0 to nmcli device modify "eth0" ipv4.addresses "172.16.5.3/24,172.16.5.4/24" ipv4.routes "172.16.5.0/24 0.0.0.0 10 table=30200, 0.0.0.0/0 172.16.5.1 10 table=30400" ipv4.routing-rules "priority 30200 from 172.16.5.3/32 table 30200, priority 30200 from 172.16.5.4/32 table 30200, priority 20350 table main suppress_prefixlength 0, priority 30400 from 172.16.5.3/32 table 30400, priority 30400 from 172.16.5.4/32 table 30400". Note that this replaces the previous addresses, routes and rules with the new information. But also note that this only changes the run time configuration of the device. The connection profile on disk is not affected.

### Google Cloud Platform (GCP)
For GCP, the meta data is fetched from URIs starting with http://metadata.google.internal/computeMetadata/v1/ with a HTTP header "Metadata-Flavor: Google". Currently, the tool only configures IPv4 and does nothing about IPv6. It will do the following.

•First fetch http://metadata.google.internal/computeMetadata/v1/instance/id to detect whether the tool runs on Google Cloud Platform. Only if the platform is detected, it will continue fetching the configuration.

•Fetch http://metadata.google.internal/computeMetadata/v1/instance/network-interfaces/ to get the list of available interface indexes. These indexes can be used for further lookups.

•Then, for each interface fetch http://metadata.google.internal/computeMetadata/v1/instance/network-interfaces/$IFACE_INDEX/mac to get the corresponding MAC address of the found interfaces. The MAC address is used to identify the device later on.

•Then, for each interface with a MAC address fetch http://metadata.google.internal/computeMetadata/v1/instance/network-interfaces/$IFACE_INDEX/forwarded-ips/ and then all the found IP addresses at http://metadata.google.internal/computeMetadata/v1/instance/network-interfaces/$IFACE_INDEX/forwarded-ips/$FIPS_INDEX.

•At this point, we have a list of all interfaces (by MAC address) and their configured IPv4 addresses. For each device, we lookup the currently applied connection in NetworkManager. That implies, that the device is currently activated in NetworkManager. If no such device was in NetworkManager, or if the profile has user-data org.freedesktop.nm-cloud-setup.skip=yes, we skip the device. Now for each found IP address we add a static route "$FIPS_ADDR/32 0.0.0.0 100 type=local" and reapply the change.

The effect is not unlike calling nmcli device modify "$DEVICE" ipv4.routes "$FIPS_ADDR/32 0.0.0.0 100 type=local [,...]" for all relevant devices and all found addresses.

### Microsoft Azure
For Azure, the meta data is fetched from URIs starting with http://169.254.169.254/metadata/instance with a URL parameter "?format=text&api-version=2017-04-02" and a HTTP header "Metadata:true". Currently, the tool only configures IPv4 and does nothing about IPv6. It will do the following.

•First fetch http://169.254.169.254/metadata/instance?format=text&api-version=2017-04-02 to detect whether the tool runs on Azure Cloud. Only if the platform is detected, it will continue fetching the configuration.

•Fetch http://169.254.169.254/metadata/instance/network/interface/?format=text&api-version=2017-04-02 to get the list of available interface indexes. These indexes can be used for further lookups.

•Then, for each interface fetch http://169.254.169.254/metadata/instance/network/interface/$IFACE_INDEX/macAddress?format=text&api-version=2017-04-02 to get the corresponding MAC address of the found interfaces. The MAC address is used to identify the device later on.

•Then, for each interface with a MAC address fetch http://169.254.169.254/metadata/instance/network/interface/$IFACE_INDEX/ipv4/ipAddress/?format=text&api-version=2017-04-02 to get the list of (indexes of) IP addresses on that interface.

•Then, for each IP address index fetch the address at http://169.254.169.254/metadata/instance/network/interface/$IFACE_INDEX/ipv4/ipAddress/$ADDR_INDEX/privateIpAddress?format=text&api-version=2017-04-02. Also fetch the size of the subnet and prefix for the interface from http://169.254.169.254/metadata/instance/network/interface/$IFACE_INDEX/ipv4/subnet/0/address/?format=text&api-version=2017-04-02. and http://169.254.169.254/metadata/instance/network/interface/$IFACE_INDEX/ipv4/subnet/0/prefix/?format=text&api-version=2017-04-02.

•At this point, we have a list of all interfaces (by MAC address) and their configured IPv4 addresses. Then the tool configures the system like doing for AWS environment. That is, using source based policy routing with the tables/rules 30200/30400.

### Alibaba Cloud (Aliyun)
For Aliyun, the tools tries to fetch configuration from http://100.100.100.200/. Currently, it only configures IPv4 and does nothing about IPv6. It will do the following.

•First fetch http://100.100.100.200/2016-01-01/meta-data/ to determine whether the expected API is present. This determines whether Aliyun environment is detected and whether to proceed to configure the host using Aliyun meta data.

•Fetch http://100.100.100.200/2016-01-01/meta-data/network/interfaces/macs/ to get the list of available interface. Interfaces are identified by their MAC address.

•Then for each interface fetch http://100.100.100.200/2016-01-01/meta-data/network/interfaces/macs/$MAC/vpc-cidr-block, http://100.100.100.200/2016-01-01/meta-data/network/interfaces/macs/$MAC/private-ipv4s, http://100.100.100.200/2016-01-01/meta-data/network/interfaces/macs/$MAC/netmask and http://100.100.100.200/2016-01-01/meta-data/network/interfaces/macs/$MAC/gateway. Thereby we get a list of private IPv4 addresses, one CIDR subnet block and private IPv4 addresses prefix.

•Then nm-cloud-setup iterates over all interfaces for which it could fetch IP configuration. If no ethernet device for the respective MAC address is found, it is skipped. Also, if the device is currently not activated in NetworkManager or if the currently activated profile has a user-data org.freedesktop.nm-cloud-setup.skip=yes, it is skipped. Also, there is only one interface and one IP address, the tool does nothing. Then the tool configures the system like doing for AWS environment. That is, using source based policy routing with the tables/rules 30200/30400. One difference to AWS is that the gateway is also fetched via metadata instead of using the first IP address in the subnet.

### Oracle Cloud (OCI)
For OCI, the tools tries to fetch configuration from http://169.254.169.254/. Currently, it only configures IPv4 and does nothing about IPv6. It will do the following.

•First fetch http://169.254.169.254/opc/v2/instance to determine whether the expected API is present. This determines whether OCI environment is detected and whether to proceed to configure the host using OCI meta data.

•Fetch http://169.254.169.254/opc/v2/vnics to get the configuration for all the VNICs, getting their MAC address, private IP address, gateway and subnet block.

•Then nm-cloud-setup iterates over all interfaces for which it could fetch a configuration. If no ethernet device for the respective MAC address is found, it is skipped. Also, if the device is currently not activated in NetworkManager or if the currently activated profile has a user-data org.freedesktop.nm-cloud-setup.skip=yes, it is skipped. Also, there is only one interface and one IP address, the tool does nothing. Then the tool configures the system like doing for AWS environment. That is, using source based policy routing with the tables/rules 30200/30400.

## SEE ALSO
NetworkManager(8) nmcli(1)


NetworkManager

package: NetworkManager-daemon

title: NetworkManager(8)

summary: network management daemon

text:
# NetworkManager(8)

## NAME
NetworkManager - network management daemon

## SYNOPSIS
NetworkManager [OPTIONS...]

## DESCRIPTION
The NetworkManager daemon attempts to make networking configuration and operation as painless and automatic as possible by managing the primary network connection and other network interfaces, like Ethernet, Wi-Fi, and Mobile Broadband devices. NetworkManager will connect any network device when a connection for that device becomes available, unless that behavior is disabled. Information about networking is exported via a D-Bus interface to any interested application, providing a rich API with which to inspect and control network settings and operation.

## DISPATCHER SCRIPTS
NetworkManager-dispatcher service can execute scripts for the user in response to network events. See NetworkManager-dispatcher(8) manual.

## OPTIONS
The following options are understood:

--version | -V

Print the NetworkManager software version and exit.

--help | -h

Print NetworkManager's available options and exit.

--no-daemon | -n

Do not daemonize.

--debug | -d

Do not daemonize, and direct log output to the controlling terminal in addition to syslog.

--pid-file | -p

Specify location of a PID file. The PID file is used for storing PID of the running process and prevents running multiple instances.

--state-file

Specify file for storing state of the NetworkManager persistently. If not specified, the default value of /var/lib/NetworkManager/NetworkManager.state is used.

--config

Specify configuration file to set up various settings for NetworkManager. If not specified, the default value of /etc/NetworkManager/NetworkManager.conf is used with a fallback to the older 'nm-system-settings.conf' if located in the same directory. See NetworkManager.conf(5) for more information on configuration file.

--configure-and-quit [initrd]

Quit after all devices reach a stable state. The optional initrd parameter enables mode, where no processes are left running after NetworkManager stops, which is useful for running from an initial ramdisk on rearly boot.

--plugins

List plugins used to manage system-wide connection settings. This list has preference over plugins specified in the configuration file. See main.plugins setting in NetworkManager.conf(5) for supported options.

--log-level

Sets how much information NetworkManager sends to the log destination (usually syslog's "daemon" facility). By default, only informational, warning, and error messages are logged. See the section on logging in NetworkManager.conf(5) for more information.

--log-domains

A comma-separated list specifying which operations are logged to the log destination (usually syslog). By default, most domains are logging-enabled. See the section on logging in NetworkManager.conf(5) for more information.

--print-config

Print the NetworkManager configuration to stdout and exit. See NetworkManager.conf(5). This does not include connection profiles. View them with nmcli connection. This reads configuration files from disk. If NetworkManager is currently running, make sure that it has the same configuration loaded.

## UDEV PROPERTIES
udev(7) device manager is used for the network device discovery. The following property influences how NetworkManager manages the devices:

NM_UNMANAGED

If set to "1" or "true", the device is configured as unmanaged by NetworkManager. Note that the user still can explicitly overrule this configuration via means like nmcli device set "$DEVICE" managed yes or "device*.managed=1" in NetworkManager.conf.

ID_NET_MANAGED_BY

If NM_UNMANAGED is set, this has no effect. Otherwise, if the attribute is set to anything but "org.freedesktop.NetworkManager", the device is unmanaged.

NM_AUTO_DEFAULT_LINK_LOCAL_ONLY

If set to "1" or "true", the automatically generated connections "Wired connection N" will only enable link local addressing for IPv4 and IPv6. This can be useful on thunderbolt devices or host-to-host USB devices.

ID_NET_AUTO_LINK_LOCAL_ONLY

Honored and treated the same as if NM_AUTO_DEFAULT_LINK_LOCAL_ONLY were set.

ID_NET_DHCP_BROADCAST

If set to "1" or "true", use broadcast requests for DHCPv4 offers. This can make sense of devices that can't handle unicast messages until being configured.

## SIGNALS
NetworkManager process handles the following signals:

SIGHUP

The signal causes a reload of NetworkManager's configuration. Note that not all configuration parameters can be changed at runtime and therefore some changes may be applied only after the next restart of the daemon. A SIGHUP also involves further reloading actions, like doing a DNS update and restarting the DNS plugin. The latter can be useful for example when using the dnsmasq plugin and changing its configuration in /etc/NetworkManager/dnsmasq.d. However, it also means this will shortly interrupt name resolution. In the future, there may be further actions added. A SIGHUP means to update NetworkManager configuration and reload everything that is supported. Note that this does not reload connections from disk. For that there is a D-Bus API and nmcli's reload action

SIGUSR1

The signal forces a rewrite of DNS configuration. Contrary to SIGHUP, this does not restart the DNS plugin and will not interrupt name resolution. When NetworkManager is not managing DNS, the signal forces a restart of operations that depend on the DNS configuration (like the resolution of the system hostname via reverse DNS, or the resolution of WireGuard peers); therefore, it can be used to tell NetworkManager that the content of resolv.conf was changed externally. In the future, further actions may be added. A SIGUSR1 means to write out data like resolv.conf, or refresh a cache. It is a subset of what is done for SIGHUP without reloading configuration from disk.

SIGUSR2

The signal has no effect at the moment but is reserved for future use.

An alternative to a signal to reload configuration is the Reload D-Bus call. It allows for more fine-grained selection of what to reload, it only returns after the reload is complete, and it is guarded by PolicyKit.

## DEBUGGING
NetworkManager only configures your system. So when your networking setup doesn't work as expected, the first step is to look at your system to understand what is actually configured, and whether that is correct. The second step is to find out how to tell NetworkManager to do the right thing.

You can for example try to ping hosts (by IP address or DNS name), look at ip link show, ip address show and ip route show, and look at /etc/resolv.conf for name resolution issues. Also look at the connection profiles that you have configured in NetworkManager (nmcli connection and nmcli connection show "$PROFILE") and the configured interfaces (nmcli device).

If that does not suffice, look at the logfiles of NetworkManager. NetworkManager logs to syslog, so depending on your system configuration you can call journalctl to get the logs. By default, NetworkManager logs are not verbose and thus not very helpful for investigating a problem in detail. You can change the logging level at runtime with nmcli general logging level TRACE domains ALL. But usually a better way is to collect full logs from the start, by configuring level=TRACE in NetworkManager.conf. See NetworkManager.conf(5) manual. Note that trace logs of NetworkManager are verbose and systemd-journald might rate limit some lines. Possibly disable rate limiting first with the RateLimitIntervalSec and RateLimitBurst options of journald (see journald.conf(5) manual).

NetworkManager does not log any secrets. However, you are advised to check whether anything private sensitive gets logged before posting. When reporting an issue, provide complete logs and avoid modifications (for privacy) that distort the meaning.

## /VAR/LIB/NETWORKMANAGER/SECRET_KEY AND /ETC/MACHINE-ID
The identity of a machine is important as various settings depend on it. For example, ipv6.addr-gen-mode=stable and ethernet.cloned-mac-address=stable generate identifiers by hashing the machine's identity. See also the connection.stable-id connection property which is a per-profile seed that gets hashed with the machine identity for generating such addresses and identifiers.

If you backup and restore a machine, the identity of the machine probably should be preserved. In that case, preserve the files /var/lib/NetworkManager/secret_key and /etc/machine-id. On the other hand, if you clone a virtual machine, you probably want that the clone has a different identity. There is already existing tooling on Linux for handling /etc/machine-id (see machine-id(5)).

The identity of the machine is determined by the /var/lib/NetworkManager/secret_key. If such a file does not exist, NetworkManager will create a file with random content. To generate a new identity just delete the file and after restart a new file will be created. The file should be read-only to root and contain at least 16 bytes that will be used to seed the various places where a stable identifier is used.

Since 1.16.0, NetworkManager supports a version 2 of secret-keys. For such keys /var/lib/NetworkManager/secret_key starts with ASCII "nm-v2:" followed by at least 32 bytes of random data. Also, recent versions of NetworkManager always create such kinds of secret-keys, when the file does not yet exist. With version 2 of the secret-key, /etc/machine-id is also hashed as part of the generation for addresses and identifiers. The advantage is that you can keep /var/lib/NetworkManager/secret_key stable, and only regenerate /etc/machine-id when cloning a VM.

## BUGS
Please report any bugs you find in NetworkManager at the NetworkManager issue tracker[1].

## SEE ALSO
NetworkManager home page[2], NetworkManager.conf(5), NetworkManager-dispatcher(8), NetworkManager-wait-online.service(8), nmcli(1), nmcli-examples(7), nm-online(1), nm-settings-nmcli(5), nm-applet(1), nm-connection-editor(1), udev(7)

## NOTES
1.

NetworkManager issue tracker

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues

2.

NetworkManager home page

https://networkmanager.dev


NetworkManager-dispatcher

title: NetworkManager-dispatcher(8)

text:
# NetworkManager-dispatcher(8)

## NAME
NetworkManager-dispatcher - Dispatch user scripts for NetworkManager

## SYNOPSIS
NetworkManager [OPTIONS...]

## DESCRIPTION
NetworkManager-dispatcher service is a D-Bus activated service that runs user provided scripts upon certain changes in NetworkManager.

NetworkManager-dispatcher will execute scripts in the /{etc,usr/lib}/NetworkManager/dispatcher.d directory or subdirectories in alphabetical order in response to network events. Files in /etc take precedence over identically-named files in /usr/lib. Each script should be a regular executable file owned by root. Furthermore, it must not be writable by group or other, and not setuid.

Each script receives two arguments, the first being the interface name of the device an operation just happened on, and second the action. For device actions, the interface is the name of the kernel interface suitable for IP configuration. Thus it is either VPN_IP_IFACE, DEVICE_IP_IFACE, or DEVICE_IFACE, as applicable. For the hostname action the device name is always "none". For connectivity-change and dns-change it is empty.

The actions are:

pre-up

The interface is connected to the network but is not yet fully activated. Scripts acting on this event must be placed or symlinked into the /etc/NetworkManager/dispatcher.d/pre-up.d directory, and NetworkManager will wait for script execution to complete before indicating to applications that the interface is fully activated.

up

The interface has been activated.

pre-down

The interface will be deactivated but has not yet been disconnected from the network. Scripts acting on this event must be placed or symlinked into the /etc/NetworkManager/dispatcher.d/pre-down.d directory, and NetworkManager will wait for script execution to complete before disconnecting the interface from its network. Note that this event is not emitted for forced disconnections, like when carrier is lost or a wireless signal fades. It is only emitted when there is an opportunity to cleanly handle a network disconnection event.

down

The interface has been deactivated.

vpn-pre-up

The VPN is connected to the network but is not yet fully activated. Scripts acting on this event must be placed or symlinked into the /etc/NetworkManager/dispatcher.d/pre-up.d directory, and NetworkManager will wait for script execution to complete before indicating to applications that the VPN is fully activated.

vpn-up

A VPN connection has been activated.

vpn-pre-down

The VPN will be deactivated but has not yet been disconnected from the network. Scripts acting on this event must be placed or symlinked into the /etc/NetworkManager/dispatcher.d/pre-down.d directory, and NetworkManager will wait for script execution to complete before disconnecting the VPN from its network. Note that this event is not emitted for forced disconnections, like when the VPN terminates unexpectedly or general connectivity is lost. It is only emitted when there is an opportunity to cleanly handle a VPN disconnection event.

vpn-down

A VPN connection has been deactivated.

hostname

The system hostname has been updated. Use gethostname(2) to retrieve it. The interface name (first argument) is empty and no environment variable is set for this action.

dhcp4-change

The DHCPv4 lease has changed (renewed, rebound, etc).

dhcp6-change

The DHCPv6 lease has changed (renewed, rebound, etc).

connectivity-change

The network connectivity state has changed (no connectivity, went online, etc).

reapply

The connection was reapplied on the device.

dns-change

The DNS configuration has changed. This action is raised even if NetworkManager is configured to not manage resolv.conf (for example, via dns=none). In such case, the dispatch script can discover the DNS configuration provided by currently active connections by looking at file /run/NetworkManager/resolv.conf

device-add

This action is called when a connection of type generic has the generic.device-handler property set. The property indicates the name of a dispatcher script to be executed in directory /{etc,usr/lib}/NetworkManager/dispatcher.d/device. Note that differently from other actions, only one script is executed. The script needs to perform any action needed to create the device for the generic connection. On successful termination, the script returns zero. Otherwise, it returns a non-zero value to indicate an error. The script can return values to NetworkManager by writing to standard output; each line should contain a key name followed by the equal sign '=' and a key value. The keys understood at the moment are:

IFINDEX

Indicates the interface index of the interface created by the script. This key is required when the script succeeds; if it is not set, the activation will fail. The key is ignored in case of script failure.

ERROR

Specifies an error message indicating the cause of the script failure. It is ignored when the script succeeds.

Since the dispatcher service captures stdout for parsing those keys, anything written to stdout will not appear in the dispatcher service journal log. Use stderr if you want to print messages to the journal (for example, for debugging). Only the first 8KiB of stdout are considered and among those, only the first 64 lines; the rest is ignored.

device-delete

This action is the counterpart of device-add and is called to delete the device for a generic connection. All the aspects described for device-add also apply to this action, with the only exception that key IFINDEX is ignored. It is not necessary to delete the kernel link in the handler because NetworkManager already does that; therefore the action is useful for any additional cleanup needed.

The environment contains more information about the interface and the connection. The following variables are available for the use in the dispatcher scripts:

NM_DISPATCHER_ACTION

The dispatcher action like "up" or "dhcp4-change", identical to the first command line argument. Since NetworkManager 1.12.0.

CONNECTION_UUID

The UUID of the connection profile.

CONNECTION_ID

The name (ID) of the connection profile.

CONNECTION_DBUS_PATH

The NetworkManager D-Bus path of the connection.

CONNECTION_FILENAME

The backing file name of the connection profile (if any).

CONNECTION_EXTERNAL

If "1", this indicates that the connection describes a network configuration created outside of NetworkManager.

DEVICE_IFACE

The interface name of the control interface of the device. Depending on the device type, this differs from DEVICE_IP_IFACE. For example for ADSL devices, this could be 'atm0' or for WWAN devices it might be 'ttyUSB0'.

DEVICE_IP_IFACE

The IP interface name of the device. This is the network interface on which IP addresses and routes will be configured.

IP4_ADDRESS_N

The IPv4 address in the format "address/prefix gateway", where N is a number from 0 to (# IPv4 addresses - 1). gateway item in this variable is deprecated, use IP4_GATEWAY instead.

IP4_NUM_ADDRESSES

The variable contains the number of IPv4 addresses the script may expect.

IP4_GATEWAY

The gateway IPv4 address in traditional numbers-and-dots notation.

IP4_ROUTE_N

The IPv4 route in the format "address/prefix next-hop metric", where N is a number from 0 to (# IPv4 routes - 1).

IP4_NUM_ROUTES

The variable contains the number of IPv4 routes the script may expect.

IP4_NAMESERVERS

The variable contains a space-separated list of the DNS servers.

IP4_DOMAINS

The variable contains a space-separated list of the search domains.

DHCP4_<dhcp-option-name>

If the connection used DHCP for address configuration, the received DHCP configuration is passed in the environment using standard DHCP option names, prefixed with "DHCP4_", like "DHCP4_HOST_NAME=foobar".

IP6_<name> and DHCP6_<name>

The same variables as for IPv4 are available for IPv6, but the prefixes are IP6_ and DHCP6_ instead.

CONNECTIVITY_STATE

The network connectivity state, which can take the values defined by the NMConnectivityState type, from the org.freedesktop.NetworkManager D-Bus API: UNKNOWN, NONE, PORTAL, LIMITED or FULL. Note: this variable will only be set for connectivity-change actions.

In case of VPN, VPN_IP_IFACE is set, and IP4_*, IP6_* variables with VPN prefix are exported too, like VPN_IP4_ADDRESS_0, VPN_IP4_NUM_ADDRESSES.

The content of the user setting for the connection being activated is also passed via environment variables. Each key is stored in a variable with name CONNECTION_USER_ concatenated with the encoding of the key name. The encoding works as follows:

•lowercase letters become uppercase

•uppercase letters are prefixed with an underscore

•numbers do not change

•a dot is replaced with a double underscore

•any other character is encoded with an underscore followed by its 3-digit octal representation

For example, key test.foo-Bar2 is stored in a variable named CONNECTION_USER_TEST__FOO_055_BAR2.

Dispatcher scripts are run one at a time, but asynchronously from the main NetworkManager process, and will be killed if they run for too long. If your script might take arbitrarily long to complete, you should spawn a child process and have the parent return immediately. Scripts that are symbolic links pointing inside the /etc/NetworkManager/dispatcher.d/no-wait.d/ directory are run immediately, without waiting for the termination of previous scripts, and in parallel. Also beware that once a script is queued, it will always be run, even if a later event renders it obsolete. (Eg, if an interface goes up, and then back down again quickly, it is possible that one or more "up" scripts will be run after the interface has gone down.)

## BUGS
Please report any bugs you find in NetworkManager at the NetworkManager issue tracker[1].

## SEE ALSO
NetworkManager home page[2], NetworkManager(8),

## NOTES
1.

NetworkManager issue tracker

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues

2.

NetworkManager home page

https://networkmanager.dev


NetworkManager-wait-online.service

title: NetworkManager-wait-online.service(8)

summary: Wait for the network to come online

text:
# NetworkManager-wait-online.service(8)

## NAME
NetworkManager-wait-online.service - Wait for the network to come online

## DESCRIPTION
The NetworkManager-wait-online service is a oneshot systemd service that delays reaching the network-online target until NetworkManager reports that the startup is completed on the D-Bus.

When the system boots, for example, remote mounts defined in /etc/fstab, require that the network is up. For this, these systemd units contain the After=network-online.target setting to order themselves after this target. NetworkManager-wait-online ensures that the network-online target is reached only after the network is available.

Optimally, all services on the host react dynamically to network changes and systemd services do not need to be configured to start after reaching the network-online target. In this case, NetworkManager-wait-online.service has no effect and does not delay the boot time. On the other hand, if you encounter a long boot time due to the delay of NetworkManager-wait-online, investigate the services that require network access and fix them.

Except for the time out value in the NetworkManager-wait-online.service unit, you cannot configure this service. Instead, settings in NetworkManager and the connection profiles affect the behavior:

•Startup is not complete as long as NetworkManager profiles are in an activating state. During boot, NetworkManager starts profiles with the connection.autoconnect=yes setting. If activation fails, NetworkManager retries the activation depending on the value of the connection.autoconnect-retries setting. NetworkManager reports startup complete when all profiles and devices are either activated or in a disconnect state and no further events are expected.

•When a device reaches the activate state depends on its configuration. For example, with a profile that has both IPv4 and IPv6 enabled, by default, NetworkManager considers the device as fully activated already when only one of the address families is ready. The ipv4.may-fail and ipv6.may-fail settings control this behavior. Additionally, the following settings influence when the two address families complete: ipv4.required-timeout, ipv6.required-timeout, ipv4.dhcp-timeout, and ipv6.ra-timeout. For details, see nm-settings-nmcli(5).

•NetworkManager cannot set IP addresses on bridge and bond devices that have ports that do not auto-activate. Because of this configuration error, NetworkManager-wait-online blocks until the service reaches its timeout value.

•Dispatcher scripts for the pre-up event run at a late stage during activation of a profile. These scripts block the activation for when NetworkManager considers the profile fully activated. For details, see NetworkManager-dispatcher(8).

•The property connection.wait-activation-delay adds an additional delay during activation and delays startup complete. This setting works around certain cases where a device is known to not be ready for a certain amount of time.

•The property connection.wait-device-timeout in the connection profiles cause a delay until the waiting devices appear. This is useful if the driver takes a longer time to detect the networking interfaces. This setting is similar to the connection.gateway-ping-timeout property.

•With Wi-Fi devices, NetworkManager needs to wait for the first scan result to know which networks are available. That adds a delay.

•With Ethernet devices, NetworkManager waits for the carrier until the value in [device*].carrier-wait-timeout is reached. This is because some devices take a long time to detect the carrier. Consequently, booting with cable unplugged, unnecessarily delays NetworkManager-wait-online.service.

## BUGS
Please report any bugs in NetworkManager at the NetworkManager issue tracker[1].

## SEE ALSO
NetworkManager home page[2], NetworkManager(8), nm-online(1), the network-online.target description in systemd.special(7)

## NOTES
1.

NetworkManager issue tracker

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues

2.

NetworkManager home page

https://networkmanager.dev


nm-initrd-generator

title: nm-initrd-generator(8)

text:
# nm-initrd-generator(8)

## NAME
nm-initrd-generator - early boot NetworkManager configuration generator

## SYNOPSIS
nm-initrd-generator [OPTIONS...] -- [CMDLINE...]

## DESCRIPTION
nm-initrd-generator scans the command line for options relevant to network configuration and creates configuration files for an early instance of NetworkManager run from the initial ramdisk during early boot.

## OPTIONS
-c | --connections-dir path

Output connection directory.

-p | --persistent-connections-dir path

Persistent connection directory. If it exists, rd.neednet will not cause a default connection to be generated in absence of other options.

-i | --initrd-data-dir path

Output directory for initrd data (e.g. hostname).

-d | --sysfs-dir path

The sysfs mount point.

-r | --run-config-dir path

Output directory for config files.

-s | --stdout

Dump connections to standard output. Useful for debugging.

CMDLINE

The options that appear on the kernel command line. The following options are recognized: ip

rd.route

bridge

bond

team

vlan

ib.pkey

bootdev

nameserver

net.ifnames

rd.peerdns

rd.iscsi.ibft

rd.bootif

rd.neednet

rd.ethtool

rd.net.dns

rd.net.dns-backend

rd.net.dns-resolve-mode

rd.net.timeout.dhcp

rd.net.dhcp.retry

rd.net.dhcp.vendor-class

rd.net.dhcp.dscp

rd.net.timeout.carrier

rd.znet

rd.znet_ifname

BOOTIF

Please consult the dracut.cmdline(7) manual for the documentation of the precise format of the values supported.

## DIFFERENCES FROM THE NETWORK-LEGACY DRACUT MODULE
nm-initrd-generator generates a set of connections that are then configured by the NetworkManager instance running in the initrd. There are some differences in behavior compared to the network-legacy dracut module:

•When an interface is configured with a static address and a gateway, the network-legacy module waits that the gateway responds to arping requests before proceeding, while NetworkManager doesn't.

•network-legacy configures interfaces one by one in the order in which they are announced by udev. If multiple interfaces specify a hostname (from command line or from DHCP), the one from the last interface activated wins. With NetworkManager, hostnames from command line have higher precedence over ones from DHCP, and the last that appears in the command line wins.

•NetworkManager supports the ib.pkey=PARENT.PKEY argument to set up an Infiniband partition on IPoIB parent device PARENT using the specified partition key PKEY. The partition key must be in hexadecimal notation without leading "0x", for example "ib.pkey=ib0.8004".

•NetworkManager supports the rd.ethtool=INTERFACE:AUTONEG:SPEED kernel command line option to set up ethtool NIC configuration parameters AUTONEG and SPEED. The INTERFACE being configured must be specified, and the other parameters are optional and can be left blank. When SPEED is set, duplex mode is automatically set to 'full'. INTERFACE accepts string values, AUTONEG accepts boolean values (true and false / on or off / 0 or 1), and SPEED accepts positive integer values.

•NetworkManager supports the rd.net.dns-backend=VALUE kernel command line option to configure the DNS processing mode. See the description of the "dns" key in the "main section" paragraph of NetworkManager.conf(5). For example: rd.net.dns-backend=systemd-resolved, rd.net.dns-backend=dnsconfd

•NetworkManager supports the rd.net.dns=SERVER kernel command line option to configure a global (non interface-specific) DNS server. The option can be specified multiple time to add more than one server. Each server can be specified as a plain IP or as an URI according to the description in the "global-dns-domains sections" paragraph of NetworkManager.conf(5). For example: rd.net.dns=2001:db8::1, rd.net.dns=dns+tls://192.0.2.0, rd.net.dns=dns+tls://[2001:db8::2]:5353#example.org. In addition, it supports configuring the "resolve-mode" key in the global DNS configuration via the rd.net.dns-resolve-mode command line option.

•NetworkManager supports the rd.net.dhcp.dscp={CS0|CS4|CS6} kernel command line option to set a specific DSCP (TOS) value in the IP header of DHCP messages.

## EXIT STATUS
nm-initrd-generator exits with status 0. It ignores unrecognized options and prints an error message if it encounters a malformed option.

## SEE ALSO
dracut.cmdline(7), NetworkManager(8).


pppd-pptp

package: accel-pptp

title: pppd-pptp(8)

summary: PPTP VPN plugin for

text:
# pppd-pptp(8)

## NAME
pptp.so - PPTP VPN plugin for pppd(8)

## SYNOPSIS
pppd [ options ] plugin pptp.so

## DESCRIPTION
The PPTP plugin for pppd performs interaction with pptp kernel module and has built-in call manager (client part of PPTP). It pasees necessary paremeters from options into kernel module to configure ppp-pptp channel. If it runs in client mode, then additionally call manager starts up. PPTPD daemon automaticaly invokes this plugin in server mode and passes necessary options, so additional configuration is not needed.

## OPTIONS for client mode
The PPTP plugin introduces one additional pppd option:

pptp_server server (required)

Specifies ip address or hostname of pptp server.

pptp_window packets (optional)

The amount of sliding window size. Set to 0 to turn off sliding window.

to 3-10 for low speed connections.

to >10 for hi speed connections.

pptp_phone phone (optional)

The phone string that sended to pptp server.

pptp_timeout miliseconds (optional)

Specifies timeout for waiting "ack" packet from server.

## USAGE
Sample configuration file:

```
plugin "pptp.so"
pptp_server 192.168.0.1
pptp_window 50
name myname
remotename pptp
noauth
refuse-eap
refuse-chap
refuse-mschap
nobsdcomp
nodeflate
novj
novjccomp
require-mppe-128
lcp-echo-interval 20
lcp-echo-failure  3
```

## SEE ALSO
pppd(8) pptpd(8) pptpd.conf(5)

## AUTHOR
xeb xeb@mail.ru


accton

package: acct

title: accton(8)

summary: turns process accounting on or off

text:
# accton(8)

## NAME
accton - turns process accounting on or off

## SYNOPSIS
accton

[OPTION] on|off|filename

accton

[ -V | --version ] [ -h | --help ]

## DESCRIPTION
accton filename turns on process accounting.

## OPTIONS
-V, --version

Print the version number of accton to standard output and quit.

-h, --help

Prints the usage string and default locations of system files to standard output and exits.

on

Turns on process accounting using the default accounting file name.

off

Turns off process accounting.

## FILES
acct

The system wide process accounting file. See acct(5) for further details.

## AUTHOR
The GNU accounting utilities were written by Noel Cragg <noel@gnu.ai.mit.edu>. The man page was adapted from the accounting texinfo page by Susan Kleinmann <sgk@sgk.tiac.net>.

## SEE ALSO
ac(1), last(1), lastcomm(1), acct(2), acct(5), sa(8).


dump-acct

title: dump-acct(8)

text:
# dump-acct(8)

## NAME
dump-acct - print an acct file in human-readable format.

## SYNOPSIS
dump-acct [-r|--reverse] [-R|--raw] [--format] version] [--byteswap] [--ahz] hertz] [-n|--num recs] [-h|--help] [ files]

## DESCRIPTION
dump-acct filename prints a list of all executed processes. This list is written by the kernel which must be compiled with BSD process accounting enabled (Debian kernel image have it already enabled). It must be started with accton(5). Note that on Debian systems, this is ensured via the init script /etc/init.d/acct.

All fields are separated by vertical line. Fields are: command, version, user time, system time, effective time, uid, gid, memory, io, pid, ppid, time. User, system and effective times are ticks per second. One tick is usually 1/50 of a second. The time field shows the start time of the process.

The --raw switch, as well as the --format, --byteswap, and --ahz can be used as a handy format converter.

## OPTIONS
-h, --help

Prints the usage string and default locations of system files to standard output and exits.

-n, --num recs

Number of lines to print.

-r, --reverse

Start printing from last records.

-R, --raw

Print raw records, not human-readable.

--format version

Use specified format version to display records.

--byteswap

Swap bytes endianness when reading records.

--ahz

Use specified units of time to display data from other kernel versions and architectures.

## FILES
acct

The system wide process accounting file. See acct(5) for further details.

## SEE ALSO
acct(5), ac(8).

## AUTHOR
The GNU accounting utilities were written by Noel Cragg <noel@gnu.ai.mit.edu>.

This manual page was written by Ognyan Kulev <ogi@fmi.uni-sofia.bg> and updated by Daniel Baumann <daniel@debian.org> and Mathieu Trudel <mathieu.tl@gmail.com> for the Debian project (but may be used by others).


dump-utmp

title: dump-utmp(8)

text:
# dump-utmp(8)

## NAME
dump-utmp - print a utmp file in human-readable format

## SYNOPSIS
dump-utmp [-hrR] [-n <recs>] <files>

[--num <recs>] [--raw] [--reverse] [--help]

## OPTIONS
The following options are supported:

-h, --help

Print a help message and the default location of the process accounting file and exit.

-r, --reverse

Print the output in reverse order.

-R, --raw

The records will be printed without any parsing.

-n, --num NUMRECS

Display only the first NUMRECS number of records.

## SEE ALSO
accton (8), lastcomm (1), utmp (5)


sa

title: sa(8)

summary: summarizes accounting information

text:
# sa(8)

## NAME
sa - summarizes accounting information

## SYNOPSIS
sa

[ -a | --list-all-names ]

[ -b | --sort-sys-user-div-calls ]

[ -c | --percentages ] [ -d | --sort-avio ]

[ -D | --sort-tio ] [ -f | --not-interactive ]

[ -i | --dont-read-summary-files ]

[ -j | --print-seconds ] [ -k | --sort-cpu-avmem ]

[ -K | --sort-ksec ] [ -l | --separate-times ]

[ -m | --user-summary ] [ -n | --sort-num-calls ]

[ -p | --show-paging ] [ -P | --show-paging-avg ]

[ -r | --reverse-sort ] [ -s | --merge ]

[ -t | --print-ratio ] [ -u | --print-users ]

[ -v num | --threshold num ] [ --sort-real-time ]

[ --debug ] [ -V | --version ] [ -h | --help ]

[ --other-usracct-file filename ]

[ --other-savacct-file filename ]

[ [ --other-acct-file ] filename ] [ --ahz hz ]

## DESCRIPTION
sa summarizes information about previously executed commands as recorded in the acct file. In addition, it condenses this data into a summary file named savacct which contains the number of times the command was called and the system resources used. The information can also be summarized on a per-user basis; sa will save this information into a file named usracct.

If no arguments are specified, sa will print information about all of the commands in the acct file.

If called with a file name as the last argument, sa will use that file instead of the system's default acct file.

By default, sa will sort the output by sum of user and system time. If command names have unprintable characters, or are only called once, sa will sort them into a group called `***other'. If more than one sorting option is specified, the list will be sorted by the one specified last on the command line.

The output fields are labeled as follows:

cp

sum of system and user CPU time in minutes (unless -j or --print-seconds is specified)

re

elapsed time in minutes (unless -j or --print-seconds is specified)

k

CPU time averaged core usage, in 1k units

avio

average number of I/O operations per execution

tio

total number of I/O operations

k*sec

CPU storage integral (kilo-core seconds)

u

user CPU time in minutes (unless -j or --print-seconds is specified)

s

system CPU time in minutes (unless -j or --print-seconds is specified)

Note that these column titles do not appear in the first row of the table, but after each numeric entry (as units of measurement) in every row. For example, you might see `79.29re', meaning 79.29 minutes or seconds of elapsed time.

An asterisk will appear after the name of commands that forked but didn't do exec.

GNU sa takes care to implement a number of features not found in other versions. For example, most versions of sa don't pay attention to flags like `--print-seconds' and `--sort-num-calls' when combined with the `--user-summary' or `--print-users' flags. GNU sa pays attention to these flags if they are applicable. Also, MIPS' sa stores the average memory use as a short rather than a double, resulting in some round-off errors. GNU sa uses double the whole way through.

## OPTIONS
The availability of these program options depends on your operating system. In specific, the members that appear in the struct acct of your system's process accounting header file (usually acct.h) determine which flags will be present. For example, if your system's struct acct doesn't have the `ac_mem' field, the installed version of sa will not support the `--sort-cpu-avmem', `--sort-ksec', `-k', or `-K' options.

In short, all of these flags may not be available on your machine.

-a, --list-all-names

Force sa not to sort those command names with unprintable characters and those used only once into the ***other group.

-b, --sort-sys-user-div-calls

Sort the output by the sum of user and system time divided by the number of calls.

-c, --percentages

Print percentages of total time for the command's user, system, and real time values.

-d, --sort-avio

Sort the output by the average number of disk I/O operations.

-D, --sort-tio

Print and sort the output by the total number of disk I/O operations.

-f, --not-interactive

When using the `--threshold' option, assume that all answers to interactive queries will be affirmative.

-i, --dont-read-summary-files

Don't read the information in the system's default savacct file.

-j, --print-seconds

Instead of printing total minutes for each category, print seconds per call.

-k, --sort-cpu-avmem

Sort the output by CPU time averaged memory usage.

-K, --sort-ksec

Print and sort the output by the CPU-storage integral.

-l, --separate-times

Print separate columns for system and user time; usually the two are added together and listed as `cp'.

-m, --user-summary

Print the number of processes and number of CPU minutes on a per-user basis.

-n, --sort-num-calls

Sort the output by the number of calls. This is the default sorting method.

-p, --show-paging

Print the number of minor and major pagefaults and swaps.

-P, --show-paging-avg

Print the number of minor and major pagefaults and swaps divided by the number of calls.

-r, --reverse-sort

Sort output items in reverse order.

-s, --merge

Merge the summarized accounting data into the summary files savacct and usracct.

-t, --print-ratio

For each entry, print the ratio of real time to the sum of system and user times. If the sum of system and user times is too small to report, `*ignore*' will appear in this field.

-u, --print-users

For each command in the accounting file, print the userid and command name. After printing all entries, quit. *Note*: this flag supersedes all others.

-v num, --threshold num

Print commands which were executed num times or fewer and await a reply from the terminal. If the response begins with `y', add the command to the `**junk**' group.

--separate-forks

It really doesn't make any sense to me that the stock version of sa separates statistics for a particular executable depending on whether or not that command forked. Therefore, GNU sa lumps this information together unless this option is specified.

--sort-real-time

Sort the output by the real time field.

--debug

Print verbose internal information.

-V, --version

Print the version number of sa.

-h, --help

Prints the usage string and default locations of system files to standard output and exits.

--other-usracct-file filename

Write summaries by user ID to filename rather than the system's default usracct file.

--other-savacct-file filename

Write summaries by command name to filename rather than the system's default savacct file.

--other-acct-file filename

Read from the file filename instead of the system's default pacct file.

--ahz hz

Use this flag to tell the program what AHZ should be (in hertz). This option is useful if you are trying to view an acct file created on another machine which has the same byte order and file format as your current machine, but has a different value for AHZ.

## FILES
acct

The raw system wide process accounting file. See acct(5) for further details.

savacct

A summary of system process accounting sorted by command.

usracct

A summary of system process accounting sorted by user ID.

## BUGS
There is not yet a wide experience base for comparing the output of GNU sa with versions of sa in many other systems. The problem is that the data files grow big in a short time and therefore require a lot of disk space.

## AUTHOR
The GNU accounting utilities were written by Noel Cragg <noel@gnu.ai.mit.edu>. The man page was adapted from the accounting texinfo page by Susan Kleinmann <sgk@sgk.tiac.net>.

## SEE ALSO
ac(1), last(1), lastcomm(1), acct(5), accton(8).


acmed

package: acmed

title: acmed(8)

summary: ACME client daemon

text:
# acmed(8)

## NAME
acmed — ACME client daemon

## SYNOPSIS
acmed

[-c|--config FILE] [-f|--foreground] [-h|--help] [--log-stderr] [--log-syslog] [--log-level LEVEL] [--no-pid-file] [--pid-file FILE] [--root-cert FILE] [-V|--version]

## DESCRIPTION
acmed is an Automatic Certificate Management Environment (ACME) client daemon which can automatically request and renew X.509 security certificates from various Certification Authorities (CA).

The options are as follows:

-c, --config FILE

Specify an alternative configuration file.

-f, --foreground

Runs in the foreground

-h, --help

Prints help information

--log-stderr

Prints log messages to the standard error output

--log-syslog

Sends log messages via syslog

--log-level LEVEL

Specify the log level. Possible values: error, warn, info, debug and trace.

--no-pid-file

Do not create any PID file

--pid-file FILE

Specifies the location of the PID file

--root-cert FILE

Add a root certificate to the trust store. This option can be used multiple times.

-V, --version

Prints version information

## FILES
/etc/acmed/acmed.toml

Default acmed configuration file.

## SEE ALSO
acmed.toml(5), tacd(8)

## STANDARDS

- R. Barnes, J. Hoffman-Andrews, D. McCarney, and J. Kasten, Automatic Certificate Management Environment (ACME), RFC 8555, March 2019.

- R.B. Shoemaker, Automated Certificate Management Environment (ACME) TLS Application-Layer Protocol Negotiation (ALPN) Challenge Extension, RFC 8737, February 2020.

- R.B. Shoemaker, Automated Certificate Management Environment (ACME) IP Identifier Validation Extension, RFC 8738, February 2020.

## AUTHORS
Rodolphe Bréard ⟨rodolphe@breard.tf⟩


tacd

title: tacd(8)

summary: TLS-ALPN Challenge Daemon

text:
# tacd(8)

## NAME
tacd — TLS-ALPN Challenge Daemon

## SYNOPSIS
tacd

[-e|--acme-ext STRING] [--acme-ext-file FILE] [--crt-digest STRING] [--crt-signature-alg STRING] [-d|--domain STRING] [--domain-file STRING] [-f|--foreground] [-h|--help] [-l|--listen host:port] [--log-stderr] [--log-syslog] [--log-level LEVEL] [--no-pid-file] [--pid-file FILE] [-V|--version]

## DESCRIPTION
tacd is a server that will listen to incoming Transport Layer Security (TLS) connections and, if the acme-tls/1 protocol has been declared during the Application-Layer Protocol Negotiation (ALPN), present a self-signed certificate in order to attempt to solve the TLS-ALPN-01 challenge. It then drops the connection.

In order to generate the self-signed certificate, it is required to specify both the domain name to validate and the acmeIdentifier extension. If one of those values is not specified using the available options, it is read from the standard input. When reading from the standard input, a new line character is expected at the end. In the case both values needs to be read from the standard input, the domain name is read first, then the acmeIdentifier extension.

The options are as follows:

-e, --acme-ext STRING

The acmeIdentifier extension to set in the self-signed certificate.

--acme-ext-file FILE

File from which is read the acmeIdentifier extension to set in the self-signed certificate.

--crt-digest STRING

Set the certificate's digest algorithm. Possible values are:

- sha256

- sha384

- sha512

--crt-signature-alg STRING

Set the certificate's signature algorithm. Possible values depends on the cryptographic library support and can be listed using the --help flag.

-d, --domain STRING

The domain that is being validated.

--domain-file STRING

File from which is read the domain that is being validated.

-f, --foreground

Runs in the foreground.

-h, --help

Prints help information.

-i, --listen host:port | unix:path

Specifies the host and port combination or the unix socket to listen on.

--log-stderr

Prints log messages to the standard error output.

--log-syslog

Sends log messages via syslog.

--log-level LEVEL

Specify the log level. Possible values: error, warn, info, debug and trace.

--no-pid-file

Do not create any PID file

--pid-file FILE

Specifies the location of the PID file.

-V, --version

Prints version information.

## SEE ALSO
acmed.toml(5)

## STANDARDS
R.B. Shoemaker, Automated Certificate Management Environment (ACME) TLS Application-Layer Protocol Negotiation (ALPN) Challenge Extension, RFC 8737, February 2020.

## AUTHORS
Rodolphe Bréard ⟨rodolphe@breard.tf⟩


package: acpid

title: acpi_listen(8)

summary: ACPI event listener

text:
# acpi_listen(8)

## NAME
acpi_listen - ACPI event listener

## SYNOPSIS
acpi_listen [options]

## DESCRIPTION
acpid is the system-wide ACPI event catcher. acpi_listen is a simple shell-friendly tool which connects to acpid and listens for events. When an event occurs, acpi_listen will print it on stdout.

## OPTIONS
-c, --count events

Receive up to a maximum number of ACPI events, then exit.

-s, --socketfile filename

This option changes the name of the UNIX domain socket which acpid opens. Default is /run/acpid.socket.

-t, --time seconds

Listen for the specified time in seconds, before exiting.

-v, --version

Print version information and exit.

-h, --help

Show help and exit.

## FILES
/run/acpid.socket

## BUGS
There are no known bugs. To file bug reports, see AUTHORS below.

## SEE ALSO
acpid(8)

## AUTHORS
Ted Felix (www.tedfelix.com)

Tim Hockin <thockin@hockin.org>

Luca Capello <luca@pca.it>


acpid

title: acpid(8)

text:
# acpid(8)

## NAME
acpid - Advanced Configuration and Power Interface event daemon

## SYNOPSIS
acpid [options]

## DESCRIPTION
acpid is designed to notify user-space programs of ACPI events. acpid should be started during the system boot, and will run as a background process, by default. It will open an events file (/proc/acpi/event by default) and attempt to read whole lines which represent ACPI events. If the events file does not exist, acpid will attempt to connect to the Linux kernel via the input layer and netlink. When an ACPI event is received from one of these sources, acpid will examine a list of rules, and execute the rules that match the event. acpid will ignore all incoming ACPI events if a lock file exists (/var/lock/acpid by default).

Rules are defined by simple configuration files. acpid will look in a configuration directory (/etc/acpi/events by default), and parse all regular files with names that consist entirely of upper and lower case letters, digits, underscores, and hyphens (similar to run-parts(8)) that do not begin with a period ('.') or end with a tilde (~). Each file must define two things: an event and an action. Any blank lines, or lines where the first character is a hash ('#') are ignored. Extraneous lines are flagged as warnings, but are not fatal. Each line has three tokens: the key, a literal equal sign, and the value. The key can be up to 63 characters, and is case-insensitive (but whitespace matters). The value can be up to 511 characters, and is case and whitespace sensitive.

The event value is a regular expression (see regcomp(3)), against which events are matched.

The action value is a commandline, which will be invoked via /bin/sh whenever an event matching the rule in question occurs. The commandline may include shell-special characters, and they will be preserved. The only special characters in an action value are "%" escaped. The string "%e" will be replaced by the literal text of the event for which the action was invoked. This string may contain spaces, so the commandline must take care to quote the "%e" if it wants a single token. The string "%%" will be replaced by a literal "%". All other "%" escapes are reserved, and will cause a rule to not load.

This feature allows multiple rules to be defined for the same event (though no ordering is guaranteed), as well as one rule to be defined for multiple events. To force acpid to reload the rule configuration, send it a SIGHUP.

The pseudo-action <drop> causes the event to be dropped completely and no further processing undertaken; clients connecting via the UNIX domain socket (see below) will not be notified of the event. This may be useful on some machines, such as certain laptops which generate spurious battery events at frequent intervals. The name of this pseudo-action may be redefined with a commandline option.

In addition to rule files, acpid also accepts connections on a UNIX domain socket (/run/acpid.socket by default). Any application may connect to this socket. Once connected, acpid will send the text of all ACPI events to the client. The client has the responsibility of filtering for messages about which it cares. acpid will not close the client socket except in the case of a SIGHUP or acpid exiting.

For faster startup, this socket can be passed in as stdin so that acpid need not create the socket. In addition, if a socket is passed in as stdin, acpid will not daemonize. It will be run in foreground. This behavior is provided to support systemd(1).

acpid will log all of its activities, as well as the stdout and stderr of any actions, to syslog.

All the default files and directories can be changed with commandline options.

## OPTIONS
-c, --confdir directory

This option changes the directory in which acpid looks for rule configuration files. Default is /etc/acpi/events.

-C, --clientmax number

This option changes the maximum number of non-root socket connections which can be made to the acpid socket. Default is 256.

-d, --debug

This option increases the acpid debug level by one.

-e, --eventfile filename

This option changes the event file from which acpid reads events. Default is /proc/acpi/event.

-n, --netlink

This option forces acpid to use the Linux kernel input layer and netlink interface for ACPI events.

-f, --foreground

This option keeps acpid in the foreground by not forking at startup, and makes it log to stderr instead of syslog.

-l, --logevents

This option tells acpid to log information about all events and actions.

-L, --lockfile filename

This option changes the lock file used to stop event processing. Default is /var/lock/acpid.

-g, --socketgroup groupname

This option changes the group ownership of the UNIX domain socket to which acpid publishes events.

-m, --socketmode mode

This option changes the permissions of the UNIX domain socket to which acpid publishes events. Default is 0666.

-s, --socketfile filename

This option changes the name of the UNIX domain socket which acpid opens. Default is /run/acpid.socket.

-S, --nosocket

This option tells acpid not to open a UNIX domain socket. This overrides the -s option, and negates all other socket options.

-p, --pidfile filename

This option tells acpid to use the specified file as its pidfile. If the file exists, it will be removed and over-written. Default is /run/acpid.pid.

-r, --dropaction action

This option defines the pseudo-action which tells acpid to abort all processing of an event, including client notifications. Default is <drop>.

-t, --tpmutefix

This option enables special handling of the mute button for certain ThinkPad models with mute LEDs that get out of sync with the mute state when the mute button is held down. With this option, the mute button will generate the following events in sync with the number of presses (and, by extension, the state of the LED):

button/mute MUTE (key pressed) K

button/mute MUTE (key released) K

-v, --version

Print version information and exit.

-h, --help

Show help and exit.

## EXAMPLE
This example will shut down your system if you press the power button.

Create a file named /etc/acpi/events/power that contains the following:

event=button/power

action=/etc/acpi/power.sh "%e"

Then create a file named /etc/acpi/power.sh that contains the following:

/sbin/shutdown -h now "Power button pressed"

Now, when acpid is running, a press of the power button will cause the rule in /etc/acpi/events/power to trigger the script in /etc/acpi/power.sh. The script will then shut down the system.

## TROUBLESHOOTING
acpid is a simple program that runs scripts in response to ACPI events from the kernel. When there's trouble, the problem is rarely with acpid itself. The following are some suggestions for finding the most common sources of ACPI-related problems.

When troubleshooting acpid, it is important to be aware that other parts of a system might be handling ACPI events. systemd(1) is capable of handling the power switch and various other events that are commonly handled by acpid. See the description of HandlePowerKey in logind.conf(5) for more. Some window managers also take over acpid's normal handling of the power button and other events.

kacpimon(8) can be used to verify that the expected ACPI events are coming in. See the man page for kacpimon(8) for the proper procedure. If the events aren't coming in, you've probably got a kernel driver issue.

If the expected events are coming in, then you'll need to check and see if your window manager is responsible for handling these events. Some are, some aren't. (E.g. in Ubuntu 14.04 (Unity/GNOME), there are settings for the laptop lid in the System Settings > Power > "When the lid is closed" fields.) If your window manager is responsible for handling the problematic event, and you've got it configured properly, then you may have a window manager issue.

Lastly, take a look in /etc/acpi/events (see above). Is there a configuration file in there for the event in question (e.g. /etc/acpi/events/lidbtn for laptop lid open/close events)? Is it properly connected to a script (e.g. /etc/acpi/lid.sh)? Is that script working? It's not unusual for an acpid script to check and see if there is a window manager running, then do nothing if there is. This means it is up to the window manager to handle this event.

## DEPENDENCIES
acpid should work on any linux kernel released since 2003.

## FILES
/proc/acpi/event

/dev/input/event*

/etc/acpi/

/run/acpid.socket

/run/acpid.pid

/var/lock/acpid

## BUGS
There are no known bugs. To file bug reports, see PROJECT WEBSITE below.

## SEE ALSO
regcomp(3) sh(1) socket(2) connect(2) init(1) systemd(1) acpi_listen(8) kacpimon(8)

## PROJECT WEBSITE
http://sourceforge.net/projects/acpid2/

## AUTHORS
Ted Felix <ted@tedfelix.com>

Tim Hockin <thockin@hockin.org>

Andrew Henroid


kacpimon

title: kacpimon(8)

summary: Kernel ACPI Event Monitor

text:
# kacpimon(8)

## NAME
kacpimon - Kernel ACPI Event Monitor

## SYNOPSIS
kacpimon

## DESCRIPTION
kacpimon is a monitor program that connects to three sources of ACPI events:

1. /proc/acpi/event

2. netlink

3. the input layer (/dev/input/event*)

kacpimon then reports on what it sees while it is connected.

Use kacpimon to make sure your kernel is sending acpi-related events via the three sources mentioned above.

Since both acpid(8) and kacpimon connect to the same sources, be sure to stop acpid(8) before running kacpimon. If you are using upstart(7), use initctl(8) to stop acpid(8). If you are using systemd(1), use systemctl(1) to stop acpid(8). If you aren't using either of those, you can try killall(1) to stop acpid(8).

Be sure to run kacpimon as root or else it won't be able to open /proc/acpi/event or the input layer:

sudo kacpimon

If you want to pipe the output of kacpimon to a file, be sure to use the "Esc" key to exit rather than Ctrl-C. Using Ctrl-C will cause output to be lost.

## FILES
/proc/acpi/event

kernel ACPI event file

/dev/input/event*

input layer event files

## SEE ALSO
acpi_listen(8), acpid(8)

## AUTHOR
Ted Felix <www.tedfelix.com>

## TODO
- Make kacpimon something that actually gets installed?

## LICENSE
kacpimon - Kernel ACPI Event Monitor

Copyright (C) 2009-2013 Ted Felix (www.tedfelix.com)

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

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

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