• Thomas Haller's avatar
    dns/dnsmasq: refactor tracking of dnsmasq process · a780b048
    Thomas Haller authored
    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.
    a780b048
nm-shared-utils.h 44.9 KB