In message [EMAIL PROTECTED], Tim
Williams wrote:
On 29/09/06, Matthew Warren [EMAIL PROTECTED] wrote:
I have found that in real usage of other programs within the company that
use lockfiles, it sometimes causes a bit of troubleshooting time when it
stops working due to a stale lockfile..
MonkeeSage wrote:
Eric S. Johansson wrote:
the problem with this solution is that it does not handle the read
nonexclusive/write exclusive locking model. In this model, reads don't
block, they only register that the request is in process. writes lock
request block until all outstanding
Fredrik Lundh wrote:
Hari Sekhon wrote:
I'm not sure if that is a very old way of doing it, which is why I was
reluctant to do it. My way actually uses the process list of the os
(linux) and counts the number of instances. If it is more than 0 then
another process is running
AMENDMENT:
The line
number_procs=commands.getstatusoutput('ps -ef|grep %s|grep -v grep|wc
-l' % scriptpath)
was supposed to be
number_procs=int(commands.getstatusoutput('ps -ef|grep %s|grep -v
grep|wc
-l' % scriptpath)[1])
-h
Hari Sekhon
Hari Sekhon wrote:
Fredrik Lundh wrote:
Hari Sekhon wrote:
How exactly do you check that the pid is still active in python? Is
there a library or something that will allow me to manipulate system
processes and listings etc the way everybody does in unix shells
by passing zero to the os.kill primitive:
os.kill(pid, 0)
The name thing is taken care of by the fact that I use the path not
just the script name. The path appears in the command and then is
grepped out by that criteria, so if there was another program with the
same name and in a different path then it would not affect it.
Of course this is
Here's a class using Fredrik's suggestions to provide generic,
cross-platform file locking (only tested on *nix however, with the two
test files listed [i.e., run test1.py in one terminal then test2.py in
another]):
http://pastie.caboo.se/15851
Ps. The lockfile should also always be cleaned up
MonkeeSage wrote:
Here's a class using Fredrik's suggestions to provide generic,
cross-platform file locking (only tested on *nix however, with the two
test files listed [i.e., run test1.py in one terminal then test2.py in
another]):
http://pastie.caboo.se/15851
Ps. The lockfile should
Eric S. Johansson wrote:
the problem with this solution is that it does not handle the read
nonexclusive/write exclusive locking model. In this model, reads don't
block, they only register that the request is in process. writes lock
request block until all outstanding reads have completed.
Apologies for repost. not sure what
happened.
This email is confidential and may be privileged. If you are not the intended recipient please notify the sender immediately and delete the email from your computer.
You should not copy the email, use it for any purpose or disclose its contents
Hari Sekhon wrote:
I have written a script and I would like to ensure that the script is
never run more than once at any given time.
What is the best way of testing and exiting if there is another version
of this script running somewhere on this machine?
I guess what I'm asking is how to
A very brutal but simple and effective method is to bind() to a socket
on localhost eg (127.0.0.1, 4711), listen() but never accept().
Any other process trying to to bind() on the same port will fail..
When the process dies, the port is released automatically, pending som
timedelay..
But this
Seeing as there doesn't seem to be a good answer to this (or at least
not one that we have so far some up with) I have decided to fall back to
my old friend the unix shell. It's as portable as python, but is very
flexible and fast at doing real things and will tell me if another
process by
Hari Sekhon [EMAIL PROTECTED] writes:
Seeing as there doesn't seem to be a good answer to this (or at least
not one that we have so far some up with) I have decided to fall back
to my old friend the unix shell. It's as portable as python, but is
very flexible and fast at doing real things and
I'm not sure if that is a very old way of doing it, which is why I was
reluctant to do it. My way actually uses the process list of the os
(linux) and counts the number of instances. If it is more than 0 then
another process is running and the script exits gracefully.
Also, apart from the
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of Hari SekhonSent: 29 September 2006 14:55To:
python-list@python.orgSubject: Re: Making sure script only runs
once instance at a time.
I'm not sure if that is a very old way of doing it, which is why I
Hari Sekhon wrote:
I'm not sure if that is a very old way of doing it, which is why I was
reluctant to do it. My way actually uses the process list of the os
(linux) and counts the number of instances. If it is more than 0 then
another process is running and the script exits gracefully.
On 29/09/06, Matthew Warren [EMAIL PROTECTED] wrote:
I have
found that in real usage of other programs within the company that use
lockfiles, it sometimes causes a bit of troubleshooting time when it stops
working due to a stale lockfile.. This especially happens when the program
is killed,
Tim Williams wrote:
def check_lock():
import os, sys
try:
os.remove({filename})
except:
if Permission denied in sys.exc_info()[1]:
print 'This program is already running'
sys.exit()
f_lock = open({filename},'w')
have you actually
On 29/09/06, Fredrik Lundh [EMAIL PROTECTED] wrote:
Tim Williams wrote:
def check_lock():
import os, sys
try:
os.remove({filename})
except:
if Permission denied in sys.exc_info()[1]:
print 'This program is already running'
Tim Williams enlightened us with:
def check_lock():
import os, sys
try:
os.remove({filename})
except:
if Permission denied in sys.exc_info()[1]:
print 'This program is already running'
sys.exit()
f_lock = open({filename},'w')
On 29/09/06, Sybren Stuvel [EMAIL PROTECTED] wrote:
Checking for a lock, and later acquiring the lock, seems non-atomic to
me. It's easier to simply create a lock directory. If it fails, the
dir already exists and someone else holds the lock. If it succeeds,
the lock is immediately yours,
Tim Williams [EMAIL PROTECTED] writes:
My reply was in response to a post that mentioned a known problem with
this, what happens when the previously running program doesn't exit
gracefully, and leaves the directory in place ??
Don't use the presence or absence of a file as a lock. Have the
On 29 Sep 2006 09:47:12 -0700, Paul Rubin
http://phr.cx@nospam.invalid wrote:
Tim Williams [EMAIL PROTECTED] writes:
My reply was in response to a post that mentioned a known problem with
this, what happens when the previously running program doesn't exit
gracefully, and leaves the
Tim Williams [EMAIL PROTECTED] writes:
That's the same kind of principle as my posted snippet, it doesn't
rely on the file's presence or absence as such. It only cares when
the file exists *and* is held open by another process.When the
process exits, the lock ends without needing to
Paul Rubin wrote:
Don't use the presence or absence of a file as a lock. Have the file
there all the time, and have the app open it and use fcntl to get an
exclusive kernel lock on the file descriptor.
doesn't work on all file systems, though...
/F
--
Tim Williams wrote:
So that I know my mistake, which bit fails (the text from
sys.exc_info()[1]?? ) , or is it all complete rubbish - and not
do-able - on a *nix system ?
opening a file for writing doesn't lock it on Unix. if you want
locking, you need other mechanisms, and I'm not sure
On 29 Sep 2006 10:04:15 -0700, Paul Rubin
http://phr.cx@nospam.invalid wrote:
Tim Williams [EMAIL PROTECTED] writes:
That's the same kind of principle as my posted snippet, it doesn't
rely on the file's presence or absence as such. It only cares when
the file exists *and* is held open by
Paul Rubin wrote:
That's the same kind of principle as my posted snippet, it doesn't
rely on the file's presence or absence as such. It only cares when
the file exists *and* is held open by another process.When the
process exits, the lock ends without needing to clean up.
It works on
On 29/09/06, Fredrik Lundh [EMAIL PROTECTED] wrote:
Tim Williams wrote:
So that I know my mistake, which bit fails (the text from
sys.exc_info()[1]?? ) , or is it all complete rubbish - and not
do-able - on a *nix system ?
opening a file for writing doesn't lock it on Unix. if you want
Fredrik Lundh [EMAIL PROTECTED] writes:
opening a file for writing doesn't lock it on Unix. if you want
locking, you need other mechanisms, and I'm not sure any of them
work properly on all configurations, under all circumstances.
Hmm. What about trying to listen on a PF_UNIX socket
In message [EMAIL PROTECTED], Hari
Sekhon wrote:
I have written a script and I would like to ensure that the script is
never run more than once at any given time.
http://groups.google.co.nz/[EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list
I have written a script and I would like to ensure that the script is
never run more than once at any given time.
What is the best way of testing and exiting if there is another version
of this script running somewhere on this machine?
I guess what I'm asking is how to handle system processes
Hari Sekhon wrote:
I have written a script and I would like to ensure that the script is
never run more than once at any given time.
What is the best way of testing and exiting if there is another version
of this script running somewhere on this machine?
I guess what I'm asking is how
34 matches
Mail list logo
