Re: OS independent way to check if a python app is running?

8 views
Skip to first unread message

Simon Brunning

unread,
Dec 14, 2009, 2:36:42 PM12/14/09
to python, python-list
2009/12/14 <pyt...@bdurham.com>:
> Is there an os independent way to check if a python app is running?

if True:
print "I'm running."

;-)

--
Cheers,
Simon B.

MRAB

unread,
Dec 14, 2009, 3:35:07 PM12/14/09
to pytho...@python.org
pyt...@bdurham.com 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.
>
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

unread,
Dec 14, 2009, 3:35:58 PM12/14/09
to Simon Brunning, python-list
Simon,

> 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

unread,
Dec 14, 2009, 3:48:44 PM12/14/09
to
MRAB schrieb:

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

unread,
Dec 14, 2009, 6:46:46 PM12/14/09
to Diez B. Roggisch, pytho...@python.org
Diez,

Thank you for your sample code. That was just what we were looking for.

Regards,
Malcolm

Dan Sommers

unread,
Dec 14, 2009, 10:07:04 PM12/14/09
to pytho...@python.org
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. 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

unread,
Dec 15, 2009, 2:52:51 AM12/15/09
to Dan Sommers, pytho...@python.org
Hi Dan,

> 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

unread,
Dec 15, 2009, 4:32:04 AM12/15/09
to
"Diez B. Roggisch" <de...@nospam.web.de> writes:

> 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

unread,
Dec 15, 2009, 5:31:24 PM12/15/09
to
pyt...@bdurham.com wrote:

> 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

unread,
Dec 22, 2009, 6:27:26 PM12/22/09
to
Dan Sommers wrote:
> 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

unread,
Dec 27, 2009, 7:07:12 PM12/27/09
to Hans Mulder, pytho...@python.org
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!

Best regards,
Malcolm (OP for this thread)

Dan Sommers

unread,
Dec 27, 2009, 7:42:58 PM12/27/09
to pytho...@python.org
On Sun, 27 Dec 2009 19:07:12 -0500, python wrote:

> 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

unread,
Dec 27, 2009, 9:30:55 PM12/27/09
to Dan Sommers, pytho...@python.org
Dan,

>> 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

srid

unread,
Dec 28, 2009, 12:23:49 AM12/28/09
to

How is this different from the zc.lockfile package?
http://pypi.python.org/pypi/zc.lockfile/

-srid

Reply all
Reply to author
Forward
0 new messages