/mandos/release

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

« back to all changes in this revision

Viewing changes to plugins.d/usplash.xml

  • Committer: Teddy Hogeborn
  • Date: 2019-07-30 17:03:57 UTC
  • mto: This revision was merged to the branch mainline in revision 384.
  • 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:
2
2
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
3
3
        "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
4
4
<!ENTITY COMMANDNAME "usplash">
5
 
<!ENTITY TIMESTAMP "2009-01-04">
 
5
<!ENTITY TIMESTAMP "2019-02-10">
6
6
<!ENTITY % common SYSTEM "../common.ent">
7
7
%common;
8
8
]>
19
19
        <firstname>Björn</firstname>
20
20
        <surname>Påhlsson</surname>
21
21
        <address>
22
 
          <email>belorn@fukt.bsnet.se</email>
 
22
          <email>belorn@recompile.se</email>
23
23
        </address>
24
24
      </author>
25
25
      <author>
26
26
        <firstname>Teddy</firstname>
27
27
        <surname>Hogeborn</surname>
28
28
        <address>
29
 
          <email>teddy@fukt.bsnet.se</email>
 
29
          <email>teddy@recompile.se</email>
30
30
        </address>
31
31
      </author>
32
32
    </authorgroup>
33
33
    <copyright>
34
34
      <year>2008</year>
35
35
      <year>2009</year>
 
36
      <year>2010</year>
 
37
      <year>2011</year>
 
38
      <year>2012</year>
 
39
      <year>2013</year>
 
40
      <year>2014</year>
 
41
      <year>2015</year>
 
42
      <year>2016</year>
 
43
      <year>2017</year>
 
44
      <year>2018</year>
 
45
      <year>2019</year>
36
46
      <holder>Teddy Hogeborn</holder>
37
47
      <holder>Björn Påhlsson</holder>
38
48
    </copyright>
125
135
        <para>
126
136
          These variables will normally be inherited from
127
137
          <citerefentry><refentrytitle>plugin-runner</refentrytitle>
128
 
          <manvolnum>8mandos</manvolnum></citerefentry>, which will
129
 
          normally have inherited them from
130
 
          <filename>/scripts/local-top/cryptroot</filename> in the
131
 
          initial <acronym>RAM</acronym> disk environment, which will
132
 
          have set them from parsing kernel arguments and
133
 
          <filename>/conf/conf.d/cryptroot</filename> (also in the
134
 
          initial RAM disk environment), which in turn will have been
135
 
          created when the initial RAM disk image was created by
136
 
          <filename
137
 
          >/usr/share/initramfs-tools/hooks/cryptroot</filename>, by
138
 
          extracting the information of the root file system from
139
 
          <filename >/etc/crypttab</filename>.
 
138
          <manvolnum>8mandos</manvolnum></citerefentry>, which might
 
139
          have in turn inherited them from its calling process.
140
140
        </para>
141
141
        <para>
142
142
          This behavior is meant to exactly mirror the behavior of
177
177
        </listitem>
178
178
      </varlistentry>
179
179
      <varlistentry>
180
 
        <term><filename>/proc</filename></term>
 
180
        <term><filename class="directory">/proc</filename></term>
181
181
        <listitem>
182
182
          <para>
183
183
            To find the running <citerefentry><refentrytitle
216
216
      is ugly, but necessary as long as it does not support aborting a
217
217
      password request.
218
218
    </para>
 
219
    <xi:include href="../bugs.xml"/>
219
220
  </refsect1>
220
221
  
221
222
  <refsect1 id="example">
277
278
  <refsect1 id="see_also">
278
279
    <title>SEE ALSO</title>
279
280
    <para>
280
 
      <citerefentry><refentrytitle>crypttab</refentrytitle>
281
 
      <manvolnum>5</manvolnum></citerefentry>,
 
281
      <citerefentry><refentrytitle>intro</refentrytitle>
 
282
      <manvolnum>8mandos</manvolnum></citerefentry>,
282
283
      <citerefentry><refentrytitle>fifo</refentrytitle>
283
284
      <manvolnum>7</manvolnum></citerefentry>,
284
285
      <citerefentry><refentrytitle>plugin-runner</refentrytitle>