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. See
84 NetworkManager.conf(5). This does not include connection profiles.
85 View them with nmcli connection.
86 This reads configuration files from disk. If NetworkManager is
88 currently running, make sure that it has the same configuration
89 loaded.
90
92 udev(7) device manager is used for the network device discovery. The
93 following property influences how NetworkManager manages the devices:
94 NM_UNMANAGED
96 If set to "1" or "true", the device is configured as unmanaged by
97 NetworkManager. Note that the user still can explicitly overrule
98 this configuration via means like nmcli device set "$DEVICE"
99 managed yes or "device*.managed=1" in NetworkManager.conf.
100
102 NetworkManager process handles the following signals:
103 SIGHUP
105 The signal causes a reload of NetworkManager's configuration. Note
106 that not all configuration parameters can be changed at runtime and
107 therefore some changes may be applied only after the next restart
108 of the daemon. A SIGHUP also involves further reloading actions,
109 like doing a DNS update and restarting the DNS plugin. The latter
110 can be useful for example when using the dnsmasq plugin and
111 changing its configuration in /etc/NetworkManager/dnsmasq.d.
112 However, it also means this will shortly interrupt name resolution.
113 In the future, there may be further actions added. A SIGHUP means
114 to update NetworkManager configuration and reload everything that
115 is supported. Note that this does not reload connections from disk.
116 For that there is a D-Bus API and nmcli's reload action
117 SIGUSR1
119 The signal forces a rewrite of DNS configuration. Contrary to
120 SIGHUP, this does not restart the DNS plugin and will not interrupt
121 name resolution. When NetworkManager is not managing DNS, the
122 signal forces a restart of operations that depend on the DNS
123 configuration (like the resolution of the system hostname via
124 reverse DNS, or the resolution of WireGuard peers); therefore, it
125 can be used to tell NetworkManager that the content of resolv.conf
126 was changed externally. In the future, further actions may be
127 added. A SIGUSR1 means to write out data like resolv.conf, or
128 refresh a cache. It is a subset of what is done for SIGHUP without
129 reloading configuration from disk.
130 SIGUSR2
132 The signal has no effect at the moment but is reserved for future
133 use.
134 An alternative to a signal to reload configuration is the Reload D-Bus
136 call. It allows for more fine-grained selection of what to reload, it
137 only returns after the reload is complete, and it is guarded by
138 PolicyKit.
139
141 NetworkManager only configures your system. So when your networking
142 setup doesn't work as expected, the first step is to look at your
143 system to understand what is actually configured, and whether that is
144 correct. The second step is to find out how to tell NetworkManager to
145 do the right thing.
146 You can for example try to ping hosts (by IP address or DNS name), look
148 at ip link show, ip address show and ip route show, and look at
149 /etc/resolv.conf for name resolution issues. Also look at the
150 connection profiles that you have configured in NetworkManager (nmcli
151 connection and nmcli connection show "$PROFILE") and the configured
152 interfaces (nmcli device).
153 If that does not suffice, look at the logfiles of NetworkManager.
155 NetworkManager logs to syslog, so depending on your system
156 configuration you can call journalctl to get the logs. By default,
157 NetworkManager logs are not verbose and thus not very helpful for
158 investigating a problem in detail. You can change the logging level at
159 runtime with nmcli general logging level TRACE domains ALL. But usually
160 a better way is to collect full logs from the start, by configuring
161 level=TRACE in NetworkManager.conf. See NetworkManager.conf(5) manual.
162 Note that trace logs of NetworkManager are verbose and systemd-journald
163 might rate limit some lines. Possibly disable rate limiting first with
164 the RateLimitIntervalSec and RateLimitBurst options of journald (see
165 journald.conf(5) manual).
166 NetworkManager does not log any secrets. However, you are advised to
168 check whether anything private sensitive gets logged before posting.
169 When reporting an issue, provide complete logs and avoid modifications
170 (for privacy) that distort the meaning.
171
173 The identity of a machine is important as various settings depend on
174 it. For example, ipv6.addr-gen-mode=stable and
175 ethernet.cloned-mac-address=stable generate identifiers by hashing the
176 machine's identity. See also the connection.stable-id connection
177 property which is a per-profile seed that gets hashed with the machine
178 identity for generating such addresses and identifiers.
179 If you backup and restore a machine, the identity of the machine
181 probably should be preserved. In that case, preserve the files
182 /var/lib/NetworkManager/secret_key and /etc/machine-id. On the other
183 hand, if you clone a virtual machine, you probably want that the clone
184 has a different identity. There is already existing tooling on Linux
185 for handling /etc/machine-id (see machine-id(5)).
186 The identity of the machine is determined by the
188 /var/lib/NetworkManager/secret_key. If such a file does not exist,
189 NetworkManager will create a file with random content. To generate a
190 new identity just delete the file and after restart a new file will be
191 created. The file should be read-only to root and contain at least 16
192 bytes that will be used to seed the various places where a stable
193 identifier is used.
194 Since 1.16.0, NetworkManager supports a version 2 of secret-keys. For
196 such keys /var/lib/NetworkManager/secret_key starts with ASCII "nm-v2:"
197 followed by at least 32 bytes of random data. Also, recent versions of
198 NetworkManager always create such kinds of secret-keys, when the file
199 does not yet exist. With version 2 of the secret-key, /etc/machine-id
200 is also hashed as part of the generation for addresses and identifiers.
201 The advantage is that you can keep /var/lib/NetworkManager/secret_key
202 stable, and only regenerate /etc/machine-id when cloning a VM.
203
205 Please report any bugs you find in NetworkManager at the NetworkManager
206 issue tracker[1].
207
209 NetworkManager home page[2], NetworkManager.conf(5), NetworkManager-
210 dispatcher(8), NetworkManager-wait-online.service(8), nmcli(1), nmcli-
211 examples(7), nm-online(1), nm-settings(5), nm-applet(1), nm-connection-
212 editor(1), udev(7)
213
215 1. NetworkManager issue tracker
216 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues
217 2. NetworkManager home page
219 https://networkmanager.dev
220NetworkManager 1.42.8 NETWORKMANAGER(8)