summaryrefslogtreecommitdiff
path: root/src/nm-core-utils.c
diff options
context:
space:
mode:
authorThomas Haller <thaller@redhat.com>2019-08-31 09:50:54 +0200
committerThomas Haller <thaller@redhat.com>2019-09-26 08:18:58 +0200
commita780b04837f444c9dbb63d48442c78e3cc4dcfe9 (patch)
tree787042846dbbb3d5df851b060c1e5424c9cf4789 /src/nm-core-utils.c
parentb288ea139709d39648174f36eb751e0e088b5859 (diff)
downloadNetworkManager-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.c2
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);
}