Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   Python (http://www.velocityreviews.com/forums/f43-python.html)
-   -   Avoid race condition with Popen.send_signal (http://www.velocityreviews.com/forums/t807600-avoid-race-condition-with-popen-send_signal.html)

Jérôme 01-02-2012 11:09 PM

Avoid race condition with Popen.send_signal
 
Hi all.

When a subprocess is running, it can be sent a signal with the send_signal
method :

process = Popen( args)
process.send_signal(signal.SIGINT)

If the SIGINT is sent while the process has already finished, an error is
raised :

File "/usr/lib/python2.7/subprocess.py", line 1457, in send_signal
os.kill(self.pid, sig)
OSError: [Errno 3] Aucun processus de ce type

To avoid this, I can check that the process is still alive :

process = Popen( args)
process.poll()
if (None == process.returncode):
process.send_signal(signal.SIGINT)

It makes safer, but there is still an issue if the process ends between
poll() and send_signal().

What is the clean way to avoid this race condition ?

Should I use try/except to catch the error or is there a more elegant way to
go ?

Thanks.

--
Jérôme

Adam Skutt 01-03-2012 01:19 AM

Re: Avoid race condition with Popen.send_signal
 
On Jan 2, 6:09*pm, Jrme <jer...@jolimont.fr> wrote:
> Hi all.
>
> When a subprocess is running, it can be sent a signal with the send_signal
> method :
>
> process = Popen( args)
> process.send_signal(signal.SIGINT)
>
> If the SIGINT is sent while the process has already finished, an error is
> raised :
>
> * File "/usr/lib/python2.7/subprocess.py", line 1457, in send_signal
> * * os.kill(self.pid, sig)
> OSError: [Errno 3] Aucun processus de ce type
>
> To avoid this, I can check that the process is still alive :
>
> process = Popen( args)
> process.poll()
> if (None == process.returncode):
> * * process.send_signal(signal.SIGINT)
>
> It makes safer, but there is still an issue if the process ends between
> poll() and send_signal().
>
> What is the clean way to avoid this race condition ?


The fundamental race condition cannot be removed nor avoided. Ideally,
avoid the need to send the subprocess a signal in the first place. If
it cannot be avoided, then trap the exception.

Adam

Heiko Wundram 01-03-2012 12:31 PM

Re: Avoid race condition with Popen.send_signal
 
Am 03.01.2012 02:19, schrieb Adam Skutt:
> On Jan 2, 6:09 pm, Jrme<jer...@jolimont.fr> wrote:
>> What is the clean way to avoid this race condition ?

>
> The fundamental race condition cannot be removed nor avoided. Ideally,
> avoid the need to send the subprocess a signal in the first place. If
> it cannot be avoided, then trap the exception.


Yes, it can be avoided, that's what the default SIGCHLD-handling
(keeping the process as a zombie until it's explicitly collected by a
wait*()) is for, which forces the PID not to be reused by the operating
system until the parent has acknowledged (by actively calling wait*())
that the child has terminated.

--
--- Heiko.

Adam Skutt 01-03-2012 01:40 PM

Re: Avoid race condition with Popen.send_signal
 
On Jan 3, 7:31*am, Heiko Wundram <modeln...@modelnine.org> wrote:
> Am 03.01.2012 02:19, schrieb Adam Skutt:
>
> > On Jan 2, 6:09 pm, Jrme<jer...@jolimont.fr> *wrote:
> >> What is the clean way to avoid this race condition ?

>
> > The fundamental race condition cannot be removed nor avoided. Ideally,
> > avoid the need to send the subprocess a signal in the first place. *If
> > it cannot be avoided, then trap the exception.

>
> Yes, it can be avoided, that's what the default SIGCHLD-handling
> (keeping the process as a zombie until it's explicitly collected by a
> wait*()) is for, which forces the PID not to be reused by the operating
> system until the parent has acknowledged (by actively calling wait*())
> that the child has terminated.


No, you still can see ESRCH when sending signals to a zombie process.
Code that sends signals to child processes via kill(2) must be
prepared for the call to fail at anytime since the process can die at
anytime. It can't handle the signal, so it's treated as if it doesn't
exist by kill(2) in this case. However, you don't have to worry about
sending the signal to the wrong process.

Adam

Heiko Wundram 01-03-2012 01:56 PM

Re: Avoid race condition with Popen.send_signal
 
Am 03.01.2012 14:40, schrieb Adam Skutt:
> On Jan 3, 7:31 am, Heiko Wundram<modeln...@modelnine.org> wrote:
>> Yes, it can be avoided, that's what the default SIGCHLD-handling
>> (keeping the process as a zombie until it's explicitly collected by a
>> wait*()) is for, which forces the PID not to be reused by the operating
>> system until the parent has acknowledged (by actively calling wait*())
>> that the child has terminated.

>
> No, you still can see ESRCH when sending signals to a zombie process.
> Code that sends signals to child processes via kill(2) must be
> prepared for the call to fail at anytime since the process can die at
> anytime. It can't handle the signal, so it's treated as if it doesn't
> exist by kill(2) in this case. However, you don't have to worry about
> sending the signal to the wrong process.


Getting an error on kill (which you can catch) is not about the race
that the posters were speculating about (i.e., sending the signal to the
wrong process), and that's what I was trying to put straight. The only
advice that I wanted to give is:

1) before calling wait to collect the child, call kill as much as you
like, and in case it errors, ignore that,

2) after calling wait, never, ever kill, and you don't need to, because
you already know the process is gone.

There's no race possibility in this, _except_ if you alter handling of
SIGCHLD away from the default (i.e., to autocollect children), in which
case you have the possibility of a race and shooting down unrelated
processes (which the discussion was about).

--
--- Heiko.


All times are GMT. The time now is 05:38 AM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.