1NETWORKMANAGER(8) Network management daemons NETWORKMANAGER(8)
2
6 NetworkManager - network management daemon
7
9 NetworkManager [OPTIONS...]
10
12 The NetworkManager daemon attempts to make networking configuration and
13 operation as painless and automatic as possible by managing the primary
14 network connection and other network interfaces, like Ethernet, Wi-Fi,
15 and Mobile Broadband devices. NetworkManager will connect any network
16 device when a connection for that device becomes available, unless that
17 behavior is disabled. Information about networking is exported via a
18 D-Bus interface to any interested application, providing a rich API
19 with which to inspect and control network settings and operation.
20
22 NetworkManager-dispatcher service can execute scripts for the user in
23 response to network events. See NetworkManager-dispatcher(8) manual.
24
26 The following options are understood:
27 --version | -V
29 Print the NetworkManager software version and exit.
30 --help | -h
32 Print NetworkManager's available options and exit.
33 --no-daemon | -n
35 Do not daemonize.
36 --debug | -d
38 Do not daemonize, and direct log output to the controlling terminal
39 in addition to syslog.
40 --pid-file | -p
42 Specify location of a PID file. The PID file is used for storing
43 PID of the running process and prevents running multiple instances.
44 --state-file
46 Specify file for storing state of the NetworkManager persistently.
47 If not specified, the default value of
48 /var/lib/NetworkManager/NetworkManager.state is used.
49 --config
51 Specify configuration file to set up various settings for
52 NetworkManager. If not specified, the default value of
53 /etc/NetworkManager/NetworkManager.conf is used with a fallback to
54 the older 'nm-system-settings.conf' if located in the same
55 directory. See NetworkManager.conf(5) for more information on
56 configuration file.
57 --configure-and-quit [initrd]
59 Quit after all devices reach a stable state. The optional initrd
60 parameter enables mode, where no processes are left running after
61 NetworkManager stops, which is useful for running from an initial
62 ramdisk on rearly boot.
63 --plugins
65 List plugins used to manage system-wide connection settings. This
66 list has preference over plugins specified in the configuration
67 file. See main.plugins setting in NetworkManager.conf(5) for
68 supported options.
69 --log-level
71 Sets how much information NetworkManager sends to the log
72 destination (usually syslog's "daemon" facility). By default, only
73 informational, warning, and error messages are logged. See the
74 section on logging in NetworkManager.conf(5) for more information.
75 --log-domains
77 A comma-separated list specifying which operations are logged to
78 the log destination (usually syslog). By default, most domains are
79 logging-enabled. See the section on logging in
80 NetworkManager.conf(5) for more information.
81 --print-config
83 Print the NetworkManager configuration to stdout and exit.
84
86 udev(7) device manager is used for the network device discovery. The
87 following property influences how NetworkManager manages the devices:
88 NM_UNMANAGED
90 If set to "1" or "true", the device is configured as unmanaged by
91 NetworkManager. Note that the user still can explicitly overrule
92 this configuration via means like nmcli device set "$DEVICE"
93 managed yes or "device*.managed=1" in NetworkManager.conf.
94
96 NetworkManager process handles the following signals:
97 SIGHUP
99 The signal causes a reload of NetworkManager's configuration. Note
100 that not all configuration parameters can be changed at runtime and
101 therefore some changes may be applied only after the next restart
102 of the daemon. A SIGHUP also involves further reloading actions,
103 like doing a DNS update and restarting the DNS plugin. The latter
104 can be useful for example when using the dnsmasq plugin and
105 changing its configuration in /etc/NetworkManager/dnsmasq.d.
106 However, it also means this will shortly interrupt name resolution.
107 In the future, there may be further actions added. A SIGHUP means
108 to update NetworkManager configuration and reload everything that
109 is supported. Note that this does not reload connections from disk.
110 For that there is a D-Bus API and nmcli's reload action
111 SIGUSR1
113 The signal forces a rewrite of DNS configuration. Contrary to
114 SIGHUP, this does not restart the DNS plugin and will not interrupt
115 name resolution. When NetworkManager is not managing DNS, the
116 signal forces a restart of operations that depend on the DNS
117 configuration (like the resolution of the system hostname via
118 reverse DNS, or the resolution of WireGuard peers); therefore, it
119 can be used to tell NetworkManager that the content of resolv.conf
120 was changed externally. In the future, further actions may be
121 added. A SIGUSR1 means to write out data like resolv.conf, or
122 refresh a cache. It is a subset of what is done for SIGHUP without
123 reloading configuration from disk.
124 SIGUSR2
126 The signal has no effect at the moment but is reserved for future
127 use.
128 An alternative to a signal to reload configuration is the Reload D-Bus
130 call. It allows for more fine-grained selection of what to reload, it
131 only returns after the reload is complete, and it is guarded by
132 PolicyKit.
133
135 NetworkManager only configures your system. So when your networking
136 setup doesn't work as expected, the first step is to look at your
137 system to understand what is actually configured, and whether that is
138 correct. The second step is to find out how to tell NetworkManager to
139 do the right thing.
140 You can for example try to ping hosts (by IP address or DNS name), look
142 at ip link show, ip address show and ip route show, and look at
143 /etc/resolv.conf for name resolution issues. Also look at the
144 connection profiles that you have configured in NetworkManager (nmcli
145 connection and nmcli connection show "$PROFILE") and the configured
146 interfaces (nmcli device).
147 If that does not suffice, look at the logfiles of NetworkManager.
149 NetworkManager logs to syslog, so depending on your system
150 configuration you can call journalctl to get the logs. By default,
151 NetworkManager logs are not verbose and thus not very helpful for
152 investigating a problem in detail. You can change the logging level at
153 runtime with nmcli general logging level TRACE domains ALL. But usually
154 a better way is to collect full logs from the start, by configuring
155 level=TRACE in NetworkManager.conf. See NetworkManager.conf(5) manual.
156 Note that trace logs of NetworkManager are verbose and systemd-journald
157 might rate limit some lines. Possibly disable rate limiting first with
158 the RateLimitIntervalSec and RateLimitBurst options of journald (see
159 journald.conf(5) manual).
160 NetworkManager does not log any secrets. However, you are advised to
162 check whether anything private sensitive gets logged before posting.
163 When reporting an issue, provide complete logs and avoid modifications
164 (for privacy) that distort the meaning.
165
167 The identity of a machine is important as various settings depend on
168 it. For example, ipv6.addr-gen-mode=stable and
169 ethernet.cloned-mac-address=stable generate identifiers by hashing the
170 machine's identity. See also the connection.stable-id connection
171 property which is a per-profile seed that gets hashed with the machine
172 identity for generating such addresses and identifiers.
173 If you backup and restore a machine, the identity of the machine
175 probably should be preserved. In that case, preserve the files
176 /var/lib/NetworkManager/secret_key and /etc/machine-id. On the other
177 hand, if you clone a virtual machine, you probably want that the clone
178 has a different identity. There is already existing tooling on Linux
179 for handling /etc/machine-id (see machine-id(5)).
180 The identity of the machine is determined by the
182 /var/lib/NetworkManager/secret_key. If such a file does not exist,
183 NetworkManager will create a file with random content. To generate a
184 new identity just delete the file and after restart a new file will be
185 created. The file should be read-only to root and contain at least 16
186 bytes that will be used to seed the various places where a stable
187 identifier is used.
188 Since 1.16.0, NetworkManager supports a version 2 of secret-keys. For
190 such keys /var/lib/NetworkManager/secret_key starts with ASCII "nm-v2:"
191 followed by at least 32 bytes of random data. Also, recent versions of
192 NetworkManager always create such kinds of secret-keys, when the file
193 does not yet exist. With version 2 of the secret-key, /etc/machine-id
194 is also hashed as part of the generation for addresses and identifiers.
195 The advantage is that you can keep /var/lib/NetworkManager/secret_key
196 stable, and only regenerate /etc/machine-id when cloning a VM.
197
199 Please report any bugs you find in NetworkManager at the NetworkManager
200 issue tracker[1].
201
203 NetworkManager home page[2], NetworkManager.conf(5), NetworkManager-
204 dispatcher(8), NetworkManager-wait-online.service(8), nmcli(1), nmcli-
205 examples(7), nm-online(1), nm-settings(5), nm-applet(1), nm-connection-
206 editor(1), udev(7)
207
209 1. NetworkManager issue tracker
210 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues
211 2. NetworkManager home page
213 https://networkmanager.dev
214NetworkManager 1.40.10 NETWORKMANAGER(8)