'\" t
.\" Title: NetworkManager
.\" Author:
.\" Generator: DocBook XSL Stylesheets vsnapshot
.\" Date: 03/21/2022
.\" Manual: Network management daemons
.\" Source: NetworkManager 1.30.6
.\" Language: English
.\"
.TH "NETWORKMANAGER" "8" "" "NetworkManager 1\&.30\&.6" "Network management daemons"
.\" -----------------------------------------------------------------
.\" * Define some portability stuff
.\" -----------------------------------------------------------------
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.\" http://bugs.debian.org/507673
.\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.ie \n(.g .ds Aq \(aq
.el .ds Aq '
.\" -----------------------------------------------------------------
.\" * set default formatting
.\" -----------------------------------------------------------------
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
.ad l
.\" -----------------------------------------------------------------
.\" * MAIN CONTENT STARTS HERE *
.\" -----------------------------------------------------------------
.SH "NAME"
NetworkManager \- network management daemon
.SH "SYNOPSIS"
.HP \w'\fBNetworkManager\ \fR\fB[OPTIONS...]\fR\ 'u
\fBNetworkManager \fR\fB[OPTIONS...]\fR
.SH "DESCRIPTION"
.PP
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\&.
.SH "DISPATCHER SCRIPTS"
.PP
NetworkManager will execute scripts in the
/etc/NetworkManager/dispatcher\&.d
directory or subdirectories in alphabetical order in response to network events\&. Each script should be a regular executable file owned by root\&. Furthermore, it must not be writable by group or other, and not setuid\&.
.PP
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
\fIhostname\fR
action the device name is always
"none"
and for
\fIconnectivity\-change\fR
it is empty\&.
.PP
The actions are:
.PP
\fIpre\-up\fR
.RS 4
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\&.
.RE
.PP
\fIup\fR
.RS 4
The interface has been activated\&.
.RE
.PP
\fIpre\-down\fR
.RS 4
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\&.
.RE
.PP
\fIdown\fR
.RS 4
The interface has been deactivated\&.
.RE
.PP
\fIvpn\-pre\-up\fR
.RS 4
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\&.
.RE
.PP
\fIvpn\-up\fR
.RS 4
A VPN connection has been activated\&.
.RE
.PP
\fIvpn\-pre\-down\fR
.RS 4
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\&.
.RE
.PP
\fIvpn\-down\fR
.RS 4
A VPN connection has been deactivated\&.
.RE
.PP
\fIhostname\fR
.RS 4
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\&.
.RE
.PP
\fIdhcp4\-change\fR
.RS 4
The DHCPv4 lease has changed (renewed, rebound, etc)\&.
.RE
.PP
\fIdhcp6\-change\fR
.RS 4
The DHCPv6 lease has changed (renewed, rebound, etc)\&.
.RE
.PP
\fIconnectivity\-change\fR
.RS 4
The network connectivity state has changed (no connectivity, went online, etc)\&.
.RE
.PP
The environment contains more information about the interface and the connection\&. The following variables are available for the use in the dispatcher scripts:
.PP
\fINM_DISPATCHER_ACTION\fR
.RS 4
The dispatcher action like "up" or "dhcp4\-change", identical to the first command line argument\&. Since NetworkManager 1\&.12\&.0\&.
.RE
.PP
\fICONNECTION_UUID\fR
.RS 4
The UUID of the connection profile\&.
.RE
.PP
\fICONNECTION_ID\fR
.RS 4
The name (ID) of the connection profile\&.
.RE
.PP
\fICONNECTION_DBUS_PATH\fR
.RS 4
The NetworkManager D\-Bus path of the connection\&.
.RE
.PP
\fICONNECTION_FILENAME\fR
.RS 4
The backing file name of the connection profile (if any)\&.
.RE
.PP
\fICONNECTION_EXTERNAL\fR
.RS 4
If "1", this indicates that the connection describes a network configuration created outside of NetworkManager\&.
.RE
.PP
\fIDEVICE_IFACE\fR
.RS 4
The interface name of the control interface of the device\&. Depending on the device type, this differs from
\fIDEVICE_IP_IFACE\fR\&. For example for ADSL devices, this could be \*(Aqatm0\*(Aq or for WWAN devices it might be \*(AqttyUSB0\*(Aq\&.
.RE
.PP
\fIDEVICE_IP_IFACE\fR
.RS 4
The IP interface name of the device\&. This is the network interface on which IP addresses and routes will be configured\&.
.RE
.PP
\fIIP4_ADDRESS_N\fR
.RS 4
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\&.
.RE
.PP
\fIIP4_NUM_ADDRESSES\fR
.RS 4
The variable contains the number of IPv4 addresses the script may expect\&.
.RE
.PP
\fIIP4_GATEWAY\fR
.RS 4
The gateway IPv4 address in traditional numbers\-and\-dots notation\&.
.RE
.PP
\fIIP4_ROUTE_N\fR
.RS 4
The IPv4 route in the format "address/prefix next\-hop metric", where N is a number from 0 to (# IPv4 routes \- 1)\&.
.RE
.PP
\fIIP4_NUM_ROUTES\fR
.RS 4
The variable contains the number of IPv4 routes the script may expect\&.
.RE
.PP
\fIIP4_NAMESERVERS\fR
.RS 4
The variable contains a space\-separated list of the DNS servers\&.
.RE
.PP
\fIIP4_DOMAINS\fR
.RS 4
The variable contains a space\-separated list of the search domains\&.
.RE
.PP
\fIDHCP4_\fR
.RS 4
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"\&.
.RE
.PP
\fIIP6_ and DHCP6_\fR
.RS 4
The same variables as for IPv4 are available for IPv6, but the prefixes are IP6_ and DHCP6_ instead\&.
.RE
.PP
\fICONNECTIVITY_STATE\fR
.RS 4
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\&.
.RE
.PP
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\&.
.PP
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\&.)
.SH "OPTIONS"
.PP
The following options are understood:
.PP
\fB\-\-version\fR | \fB\-V\fR
.RS 4
Print the NetworkManager software version and exit\&.
.RE
.PP
\fB\-\-help\fR | \fB\-h\fR
.RS 4
Print NetworkManager\*(Aqs available options and exit\&.
.RE
.PP
\fB\-\-no\-daemon\fR | \fB\-n\fR
.RS 4
Do not daemonize\&.
.RE
.PP
\fB\-\-debug\fR | \fB\-d\fR
.RS 4
Do not daemonize, and direct log output to the controlling terminal in addition to syslog\&.
.RE
.PP
\fB\-\-pid\-file\fR | \fB\-p\fR
.RS 4
Specify location of a PID file\&. The PID file is used for storing PID of the running process and prevents running multiple instances\&.
.RE
.PP
\fB\-\-state\-file\fR
.RS 4
Specify file for storing state of the NetworkManager persistently\&. If not specified, the default value of
/var/lib/NetworkManager/NetworkManager\&.state
is used\&.
.RE
.PP
\fB\-\-config\fR
.RS 4
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 \*(Aqnm\-system\-settings\&.conf\*(Aq if located in the same directory\&. See
\fBNetworkManager.conf\fR(5)
for more information on configuration file\&.
.RE
.PP
\fB\-\-configure\-and\-quit\fR [initrd]
.RS 4
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\&.
.RE
.PP
\fB\-\-plugins\fR
.RS 4
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
\fBNetworkManager.conf\fR(5)
for supported options\&.
.RE
.PP
\fB\-\-log\-level\fR
.RS 4
Sets how much information NetworkManager sends to the log destination (usually syslog\*(Aqs "daemon" facility)\&. By default, only informational, warning, and error messages are logged\&. See the section on
logging
in
\fBNetworkManager.conf\fR(5)
for more information\&.
.RE
.PP
\fB\-\-log\-domains\fR
.RS 4
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
\fBNetworkManager.conf\fR(5)
for more information\&.
.RE
.PP
\fB\-\-print\-config\fR
.RS 4
Print the NetworkManager configuration to stdout and exit\&.
.RE
.SH "UDEV PROPERTIES"
.PP
\fBudev\fR(7)
device manager is used for the network device discovery\&. The following property influences how NetworkManager manages the devices:
.PP
\fINM_UNMANAGED\fR
.RS 4
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
\fBnmcli device set "$DEVICE" managed yes\fR
or
"device*\&.managed=1"
in NetworkManager\&.conf\&.
.RE
.SH "SIGNALS"
.PP
NetworkManager process handles the following signals:
.PP
\fISIGHUP\fR
.RS 4
The signal causes a reload of NetworkManager\*(Aqs 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\*(Aqs reload action
.RE
.PP
\fISIGUSR1\fR
.RS 4
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\&.
.RE
.PP
\fISIGUSR2\fR
.RS 4
The signal has no effect at the moment but is reserved for future use\&.
.RE
.PP
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\&.
.SH "DEBUGGING"
.PP
NetworkManager only configures your system\&. So when your networking setup doesn\*(Aqt 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\&.
.PP
You can for example try to
\fBping\fR
hosts (by IP address or DNS name), look at
\fBip link show\fR,
\fBip address show\fR
and
\fBip route show\fR, and look at
/etc/resolv\&.conf
for name resolution issues\&. Also look at the connection profiles that you have configured in NetworkManager (\fBnmcli connection\fR
and
\fBnmcli connection show "$PROFILE"\fR) and the configured interfaces (\fBnmcli device\fR)\&.
.PP
If that does not suffice, look at the logfiles of NetworkManager\&. NetworkManager logs to syslog, so depending on your system configuration you can call
\fBjournalctl\fR
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
\fBnmcli general logging level TRACE domains ALL\fR\&. But usually a better way is to collect full logs from the start, by configuring
level=TRACE
in NetworkManager\&.conf\&. See
\fBNetworkManager.conf\fR(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
\fBjournald.conf\fR(5)
manual)\&.
.SH "/VAR/LIB/NETWORKMANAGER/SECRET_KEY AND /ETC/MACHINE\-ID"
.PP
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\*(Aqs 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\&.
.PP
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
\fBmachine-id\fR(5))\&.
.PP
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\&.
.PP
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\&.
.SH "BUGS"
.PP
Please report any bugs you find in NetworkManager at the
\m[blue]\fBNetworkManager issue tracker\fR\m[]\&\s-2\u[1]\d\s+2\&.
.SH "SEE ALSO"
.PP
\m[blue]\fBNetworkManager home page\fR\m[]\&\s-2\u[2]\d\s+2,
\fBNetworkManager.conf\fR(5),
\fBnmcli\fR(1),
\fBnmcli-examples\fR(7),
\fBnm-online\fR(1),
\fBnm-settings\fR(5),
\fBnm-applet\fR(1),
\fBnm-connection-editor\fR(1),
\fBudev\fR(7)
.SH "NOTES"
.IP " 1." 4
NetworkManager issue tracker
.RS 4
\%https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues
.RE
.IP " 2." 4
NetworkManager home page
.RS 4
\%https://wiki.gnome.org/Projects/NetworkManager
.RE