Re: OS independent way to check if a python app is running?
Simon Brunning
> Is there an os independent way to check if a python app is running?
if True:
print "I'm running."
;-)
--
Cheers,
Simon B.
MRAB
> running once. If a system administrator accidentally attempts to run
> this program more than once, I would like the 2nd instance of the
> program to detect that its already running and exit.
>
You could use lockfile: http://pypi.python.org/pypi/lockfile/0.7
If a certain file exists and is locked, then the app is already running.
pyt...@bdurham.com
> if True:
> print "I'm running."
>
> ;-)
LOL! Yes, I should of worded my original post better (meant to say "...
if a python app is already running".
Enjoyed your post anyway - I'm still laughing :)
Cheers,
Malcolm
Diez B. Roggisch
Not only exists, he should also use the OS' locking mechanisms. The file
could otherwise be stale.
We use this:
import platform
is_windows = False
if platform.system() == 'Windows':
is_windows = True
import os
class LockFileCreationException(Exception):
pass
class LockFile(object):
def __init__(self, name, fail_on_lock=False, cleanup=True):
self.name = name
self.cleanup = cleanup
try:
self.fd = os.open(name, os.O_WRONLY | os.O_CREAT | os.O_APPEND)
except OSError, e:
if e[0] == 2:
raise LockFileCreationException()
self.file = os.fdopen(self.fd, "w")
if is_windows:
lock_flags = msvcrt.LK_LOCK
else:
lock_flags = fcntl.LOCK_EX
if fail_on_lock:
if is_windows:
lock_flags = msvcrt.LK_NBLCK
else:
lock_flags |= fcntl.LOCK_NB
try:
if is_windows:
msvcrt.locking(self.file.fileno(), lock_flags, 1)
else:
fcntl.flock(self.file, lock_flags)
except IOError, e:
if e[0] == 11:
raise LockObtainException()
raise
def __enter__(self):
return self.file
def __exit__(self, unused_exc_type, unused_exc_val, unused_exc_tb):
self.file.close()
# we are told to cleanup after ourselves,
# however it might be that another process
# has done so - so we don't fail in that
# case.
if self.cleanup:
try:
os.remove(self.name)
except OSError, e:
if not e[0] == 2:
raise
Diez
pyt...@bdurham.com
Thank you for your sample code. That was just what we were looking for.
Regards,
Malcolm
Dan Sommers
> Is there an os independent way to check if a python app is running?
>
> Goal: I have a server program based on cherrypy that I only want to have
> running once. If a system administrator accidentally attempts to run
> this program more than once, I would like the 2nd instance of the
> program to detect that its already running and exit.
Maybe I'm missing something, but the locking mechanism already exists:
at some point, your server program has to bind to an IP port to listen
for incoming request, and any respectable OS won't let two programs bind
to the same port at the same time. So if binding to the input port
works, then there *can't* be another instance of the program running
(multiple configuration files notwithstanding, but then you'd need a
second process anyway).
I guess I am assuming that "a server program based on cherrypy" takes its
input from an IP port, but that seems safe enough given the nature of
cherrypy.
Dan
pyt...@bdurham.com
> Maybe I'm missing something, but the locking mechanism already exists:
at some point, your server program has to bind to an IP port to listen
for incoming request, and any respectable OS won't let two programs bind
to the same port at the same time. So if binding to the input port
works, then there *can't* be another instance of the program running
(multiple configuration files notwithstanding, but then you'd need a
second process anyway).
We actually have a suite of server products which use ports in a
flexible way so your idea - although accurate - won't work in our
specific case.
MRAB and Diez posted some excellent, cross platform approaches to
locking a resource.
Thanks for your feedback.
Regards,
Malcolm
Ben Finney
> Not only exists, he should also use the OS' locking mechanisms. The
> file could otherwise be stale.
>
> We use this:
Have you tried collaborating with the ‘lockfile’ library developer to
converge these solutions?
As I understand it, the ‘lockfile’ library is meant to provide a common
API across platforms; but that doesn't prevent it from taking advantage
of OS-specific locking implementation.
--
\ “I do not believe in forgiveness as it is preached by the |
`\ church. We do not need the forgiveness of God, but of each |
_o__) other and of ourselves.” —Robert G. Ingersoll |
Ben Finney
r0g
> LOL! Yes, I should of worded my original post better (meant to say "...
> if a python app is already running".
>
> Enjoyed your post anyway - I'm still laughing :)
>
> Cheers,
> Malcolm
Quick and dirty way would be to keep a particular high numbered socket open.
Roger
Hans Mulder
> On Mon, 14 Dec 2009 14:14:05 -0500, python wrote:
>
>> Is there an os independent way to check if a python app is running?
>>
>> Goal: I have a server program based on cherrypy that I only want to have
>> running once. If a system administrator accidentally attempts to run
>> this program more than once, I would like the 2nd instance of the
>> program to detect that its already running and exit.
>
> Maybe I'm missing something, but the locking mechanism already exists:
> at some point, your server program has to bind to an IP port to listen
> for incoming request, and any respectable OS won't let two programs bind
> to the same port at the same time.
Unfortunately, Windows is not a respectable OS. Unlike Unix, it allows
two processes to bind to the same port. The theory is that this somehow
allows the two processes to share their workload.
One thing the OP can portably do, is try to connect() to the port.
If that succeeds, then a server program is already running at that port,
so he should exit.
Hope this helps,
-- HansM
pyt...@bdurham.com
> Unfortunately, Windows is not a respectable OS. Unlike Unix, it allows two processes to bind to the same port. The theory is that this somehow allows the two processes to share their workload. One thing the OP can portably do, is try to connect() to the port. If that succeeds, then a server program is already running at that port, so he should exit.
Thank you for your tip - spot on!
Best regards,
Malcolm (OP for this thread)
Dan Sommers
> Hans,
>
>> Unfortunately, Windows is not a respectable OS. Unlike Unix, it allows
>> two processes to bind to the same port. The theory is that this somehow
>> allows the two processes to share their workload. One thing the OP can
>> portably do, is try to connect() to the port. If that succeeds, then a
>> server program is already running at that port, so he should exit.
>
> Thank you for your tip - spot on!
Beware of the converse, though. If a process *cannot* connect to the
port, then it should *not* assume that another server *isn't* running.
If two potential servers both start at the same time, and each tries to
connect, then both will fail, but you don't want both to start, either.
pyt...@bdurham.com
>> Unfortunately, Windows is not a respectable OS. Unlike Unix, it allows
>> two processes to bind to the same port. The theory is that this somehow
>> allows the two processes to share their workload. One thing the OP can
>> portably do, is try to connect() to the port. If that succeeds, then a
>> server program is already running at that port, so he should exit.
> Beware of the converse, though. If a process *cannot* connect to the
> port, then it should *not* assume that another server *isn't* running.
> If two potential servers both start at the same time, and each tries to
> connect, then both will fail, but you don't want both to start, either.
Thank you for pointing out that nuance.
Best regards,
Malcolm