Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #71039 > unrolled thread

python-daemon interaction with multiprocessing (secure-smtpd)

Back to article view | Back to comp.lang.python

Contents

  python-daemon interaction with multiprocessing (secure-smtpd) Grant Edwards <invalid@invalid.invalid> - 2014-05-07 17:04 +0000
    Re: python-daemon interaction with multiprocessing (secure-smtpd) Grant Edwards <invalid@invalid.invalid> - 2014-05-07 17:55 +0000
      Re: python-daemon interaction with multiprocessing (secure-smtpd) Ben Finney <ben@benfinney.id.au> - 2014-05-08 05:01 +1000
        Re: python-daemon interaction with multiprocessing (secure-smtpd) Grant Edwards <invalid@invalid.invalid> - 2014-05-07 19:11 +0000
          Re: python-daemon interaction with multiprocessing (secure-smtpd) Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2014-05-07 21:45 +0200
    Re: python-daemon interaction with multiprocessing (secure-smtpd) Grant Edwards <invalid@invalid.invalid> - 2014-05-07 21:07 +0000

#71039 — python-daemon interaction with multiprocessing (secure-smtpd)

With Python 2.7.5, I'm trying to use the python-daemon 1.6 and its
DaemonRunner helper with the seucre-smtpd 1.1.9 which appears to use
multiprocessing and a process pool under the covers.  There seem to be
a couple process issues:

 1) The pid file created by DaemonRunner dissappears.  This seems to
    happen when the SMTP client closes the connection without saying
    goodbye first.  The process who's PID was in the pid file before
    it vanished is still running (as is the pool of worker processes),
    and they are still accepting connections and working as it should.

    Has anybody else had any luck with DaemonRunner and pidfiles?
    
 2) When DaemonRunner kills the "lead" process (the parent of the
    worker pool), the worker pools stays alive and continues to handle
    accept and handle requests.  [I've tried kill -TERM and -QUIT on
    the lead process by hand with the TERM signal, and got the same
    results: the worker pool continues to run.]

    How so you terminate a Python program that's using multiprocessing?

-- 
Grant Edwards               grant.b.edwards        Yow! Look!  A ladder!
                                  at               Maybe it leads to heaven,
                              gmail.com            or a sandwich!

[toc] | [next] | [standalone]

#71040

On 2014-05-07, Grant Edwards <invalid@invalid.invalid> wrote:
> With Python 2.7.5, I'm trying to use the python-daemon 1.6 and its
> DaemonRunner helper with the seucre-smtpd 1.1.9 which appears to use
> multiprocessing and a process pool under the covers.  There seem to be
> a couple process issues:
>
>  1) The pid file created by DaemonRunner disappears.  This seems to
>     happen when the SMTP client closes the connection without saying
>     goodbye first.

Hmm.  After some further testing, it looks like it often disappears as
soon as the first connection is accepted (which I think is when the
first worker process is created).

>     How do you terminate a Python program that's using multiprocessing?

It looks like you have to kill all the threads individually.  :/

-- 
Grant Edwards               grant.b.edwards        Yow! We are now enjoying
                                  at               total mutual interaction in
                              gmail.com            an imaginary hot tub ...

[toc] | [prev] | [next] | [standalone]

#71046

Grant Edwards <invalid@invalid.invalid> writes:

> On 2014-05-07, Grant Edwards <invalid@invalid.invalid> wrote:
> >     How do you terminate a Python program that's using multiprocessing?
>
> It looks like you have to kill all the threads individually.  :/

As I understand it, the ‘multiprocessing’ module
<URL:https://docs.python.org/3/library/multiprocessing.html> does not
create multiple threads; it creates multiple processes.

It also closely follows the API for the ‘threading’ module. That
includes the ability to manage a pool of workers
<URL:https://docs.python.org/3/library/multiprocessing.html#module-multiprocessing.pool>.

You can ask the pool of workers to close when they're done
<URL:https://docs.python.org/3/library/multiprocessing.html#multiprocessing.pool.Pool.close>.
Does that address the requirement?

-- 
 \         “Pinky, are you pondering what I'm pondering?” “I think so, |
  `\    Brain, but if we give peas a chance, won't the lima beans feel |
_o__)                                left out?” —_Pinky and The Brain_ |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#71047

On 2014-05-07, Ben Finney <ben@benfinney.id.au> wrote:
> Grant Edwards <invalid@invalid.invalid> writes:
>
>> On 2014-05-07, Grant Edwards <invalid@invalid.invalid> wrote:
>> >     How do you terminate a Python program that's using multiprocessing?
>>
>> It looks like you have to kill all the threads individually.  :/
>
> As I understand it, the ‘multiprocessing’ module
><URL:https://docs.python.org/3/library/multiprocessing.html> does not
> create multiple threads; it creates multiple processes.

Right.  I should have written processes rather than threads.

> It also closely follows the API for the ‘threading’ module. That
> includes the ability to manage a pool of workers
><URL:https://docs.python.org/3/library/multiprocessing.html#module-multiprocessing.pool>.

Except when you kill the parent of a bunch of threads, they all get
killed.  That doesn't seem to be the case for multiprocessing.

> You can ask the pool of workers to close when they're done
><URL:https://docs.python.org/3/library/multiprocessing.html#multiprocessing.pool.Pool.close>.
> Does that address the requirement?

I'm not sure.  It's not really my code that's creating and managing
the pool: that's happening inside the secure-smtpd module from
https://github.com/bcoe/secure-smtpd.  There's a little bit of wrapper
code that configures the server and then starts it -- after that I
don't have much control over anything.

Mainly, I'm just trying to figure out the right way to terminate the
server from an /etc/init script.

-- 
Grant Edwards               grant.b.edwards        Yow! We're going to a
                                  at               new disco!
                              gmail.com            

[toc] | [prev] | [next] | [standalone]

#71053

op 07-05-14 21:11, Grant Edwards schreef:
> 
> Mainly, I'm just trying to figure out the right way to terminate the
> server from an /etc/init script.
> 
As far as I understand you have to make sure that your daemon is a proces
group leader. All the children it will fork will then belong to its
proces group. You can then normally kill all process with pkill -g ...

-- 
Antoon Pardon

[toc] | [prev] | [next] | [standalone]

#71052

On 2014-05-07, Grant Edwards <invalid@invalid.invalid> wrote:

> With Python 2.7.5, I'm trying to use the python-daemon 1.6 and its
> DaemonRunner helper with the seucre-smtpd 1.1.9 which appears to use
> multiprocessing and a process pool under the covers.  There seem to be
> a couple process issues:
>
>  1) The pid file created by DaemonRunner dissappears. [...]
>
>  2) When DaemonRunner kills the "lead" process (the parent of the
>     worker pool), the worker pools stays alive and continues to handle
>     accept and handle requests. [...]

I've tracked both these problems down to a single bug in secure_smtpd.

The secure_smtpd server is a normal asyncore server until the first
connection arrives.  At that point, it creates a bunch of
multiprocessor worker processes _without_ the daemon flag which all
loop doing blocking accept() calls.  The parent process then shuts
down the asyncore server and returns.

When the parent process returns, DaemonRunner removes the pidfile,
since it thinks the server has terminated.  However, the parent
process never actually dies -- it just hangs until all the children
terminate.

At this point, killing the parent process (whose PID _was_ in the
pidfile, and is now idle) does nothing: even though the parent process
gets killed, the worker processes keeps working.

The fix is to 

 1) Change secure_smtpd to create the worker processes with daemon=True

 2) After asyncore.loop() returns (which means the children have been
    created), do a while 1: time.sleep(1) to wait for SIGTERM.

-- 
Grant Edwards               grant.b.edwards        Yow! Maybe we could paint
                                  at               GOLDIE HAWN a rich PRUSSIAN
                              gmail.com            BLUE --

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web