diff options
author | Thomas Haller <thaller@redhat.com> | 2019-08-31 09:50:54 +0200 |
---|---|---|
committer | Thomas Haller <thaller@redhat.com> | 2019-09-26 08:18:58 +0200 |
commit | a780b04837f444c9dbb63d48442c78e3cc4dcfe9 (patch) | |
tree | 787042846dbbb3d5df851b060c1e5424c9cf4789 /src/nm-core-utils.c | |
parent | b288ea139709d39648174f36eb751e0e088b5859 (diff) | |
download | NetworkManager-a780b04837f444c9dbb63d48442c78e3cc4dcfe9.tar.gz |
dns/dnsmasq: refactor tracking of dnsmasq process
Several points.
- We spawn the dnsmasq process directly. That has several downsides:
- The lifetime of the process is tied to NetworkManager's. When
stopping NetworkManager, we usually also stop dnsmasq. Or we keep
the process running, but later the process is no longer a child process
of NetworkManager and we can only kill it using the pidfile.
- We don't do special sandboxing of the dnsmasq process.
- Note that we want to ensure that only one dnsmasq process is running
at any time. We should track that in a singletone. Note that NMDnsDnsmasq
is not a singleton. While there is only one instance active at any time,
the DNS plugin can be swapped (e.g. during SIGHUP). Hence, don't track the
process per-NMDnsDnsmasq instance, but in a global variable "gl_pid".
- Usually, when NetworkManager quits, it also stops the dnsmasq process.
Previously, we would always try to terminate the process based on the
pidfile. That is wrong. Most of the time, NetworkManager spawned the
process itself, as a child process. Hence, the PID is known and NetworkManager
will get a signal when dnsmasq exits. The only moment when NetworkManager should
use the pidfile, is the first time when checking to kill the previous instance.
That is: only once at the beginning, to kill instances that were
intentionally or unintentionally (crash) left running earlier.
This is now done by _gl_pid_kill_external().
- Previously, before starting a new dnsmasq instance we would kill a
possibly already running one, and block while waiting for the process to
disappear. We should never block. Especially, since we afterwards start
the process also in non-blocking way, there is no reason to kill the
existing process in a blocking way. For the most part, starting dnsmasq
is already asynchronous and so should be the killing of the dnsmasq
process.
- Drop GDBusProxy and only use GDBusConnection. It fully suffices.
- When we kill a dnsmasq instance, we actually don't have to wait at
all. That can happen fully in background. The only pecularity is that
when we restart a new instance before the previous instance is killed,
then we must wait for the previous process to terminate first. Also, if
we are about to exit while killing the dnsmasq instance, we must register
nm_shutdown_wait_obj_*() to wait until the process is fully gone.
Diffstat (limited to 'src/nm-core-utils.c')
-rw-r--r-- | src/nm-core-utils.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/src/nm-core-utils.c b/src/nm-core-utils.c index aebab9d4ec..0d5f8f1c87 100644 --- a/src/nm-core-utils.c +++ b/src/nm-core-utils.c @@ -1100,7 +1100,7 @@ const char *const NM_PATHS_DEFAULT[] = { }; const char * -nm_utils_find_helper(const char *progname, const char *try_first, GError **error) +nm_utils_find_helper (const char *progname, const char *try_first, GError **error) { return nm_utils_file_search_in_paths (progname, try_first, NM_PATHS_DEFAULT, G_FILE_TEST_IS_EXECUTABLE, NULL, NULL, error); } |