/mandos/trunk

To get this branch, use:
bzr branch http://bzr.recompile.se/loggerhead/mandos/trunk

« back to all changes in this revision

Viewing changes to overview.xml

  • Committer: Teddy Hogeborn
  • Date: 2019-07-30 17:03:57 UTC
  • Revision ID: teddy@recompile.se-20190730170357-jte0piul5mq7j5pr
Server: Reap zombies created by multiprocessing.Process()

When creating checkers as multiprocessing.Process() objects, the
multiprocessing module also creates a parent process (for the
call_pipe() function) to call the actual checker process, but this
parent process is not reaped.  This is not a huge problem, since the
zombie is always reaped automatically the next time the multiprocess
starts a new process, but the zombies can be up to as many as there
have ever been simultaneous checker processes.  To fix this, the
process object must be join():ed when they report completion of the
child checker process.

* mandos (Client): Fix doc string to correctly state that
                   Client.checker is a multiprocess.Process() and not
                   a subprocess.Popen() object.
  (Client.checker_callback): After the returncode of the checker
                             process has been read, wait for the
                             self.checker Process object to finish by
                             calling join() on it.

Reported-by: Peter Palfrader <weasel@debian.org>

Show diffs side-by-side

added added

removed removed

Lines of Context:
8
8
  program in the initial <acronym>RAM</acronym> disk environment which
9
9
  will communicate with a server over a network.  All network
10
10
  communication is encrypted using <acronym>TLS</acronym>.  The
11
 
  clients are identified by the server using an OpenPGP key; each
12
 
  client has one unique to it.  The server sends the clients an
13
 
  encrypted password.  The encrypted password is decrypted by the
14
 
  clients using the same OpenPGP key, and the password is then used to
15
 
  unlock the root file system, whereupon the computers can continue
16
 
  booting normally.
 
11
  clients are identified by the server using a TLS key; each client
 
12
  has one unique to it.  The server sends the clients an encrypted
 
13
  password.  The encrypted password is decrypted by the clients using
 
14
  a separate OpenPGP key, and the password is then used to unlock the
 
15
  root file system, whereupon the computers can continue booting
 
16
  normally.
17
17
</para>