How can I know if my python script is running? (us

Question

I have a python script named sudoserver.py that I start in a CygWin shell by doing:

python sudoserver.py

I am planning to create a shell script (I don't know yet if I will use Windows shell script or a CygWin script) that needs to know if this sudoserver.py python script is running. But if I do in CygWin (while sudoserver.py is running):

$ ps -e | grep "python" -i
    11020   10112   11020       7160  cons0   1000 00:09:53 /usr/bin/python2.7

and in Windows shell:

C:\>tasklist | find "python" /i
python2.7.exe                 4344 Console                    1    13.172 KB

So it seems I have no info about the .py file being executed. All I know is that python is running something.
The -l (long) option for 'ps' on CygWin does not find my .py file. Nor does it the /v (verbose) switch at tasklist.
What should be the appropriate shell (Windows or CygWin shell would enough; both if possible would be fine) way to programmatically find if an specific python script is executing right now?

NOTE: The python process could be started by another user. Even from a user not logged in a GUI shell, and, even more, the "SYSTEM" (privileged) Windows user.

Answer 1

It is a limitation of the platform.

You probably need to use some low level API to retrieve the process info. You can take a look at this one: Getting the command line arguments of another process in Windows

You can probably use win32api module to access these APIs.

(Sorry, away from a Windows PC so I can't try it out)

Answer 2

Since sudoserver.py is your script, you could modify it to create a file in an accessible location when it starts and to delete the file when it finishes. Your shell script can then check for the existence of that file to find out if sudoserver.py is running.

(EDIT)

Thanks to the commenters who suggested that while the presence or absence of the file is an unreliable indicator, a file's lock status is not.

I wrote the following Python script testlock.py:

f = open ("lockfile.lck","w")
for i in range(10000000):
    print (i)
f.close()

... and ran it in a Cygwin console window on my Windows PC. At the same time, I had another Cygwin console window open in the same directory.

First, after I started testlock.py:

Simon@Simon-PC ~/test/python
$ ls
lockfile.lck  testlock.py

Simon@Simon-PC ~/test/python
$ rm lockfile.lck
rm: cannot remove `lockfile.lck': Device or resource busy

... then after I had shut down testlock.py by using Ctrl-C:

Simon@Simon-PC ~/test/python
$ rm lockfile.lck

Simon@Simon-PC ~/test/python
$ ls
testlock.py

Simon@Simon-PC ~/test/python
$

Thus, it appears that Windows is locking the file while the testlock.py script is running but it is unlocked when it is stopped with Ctrl-C. The equivalent test can be carried out in Python with the following script:

import os
try:
    os.remove ("lockfile.lck")
except:
    print ("lockfile.lck in use")

... which correctly reports:

$ python testaccess.py
lockfile.lck in use

... when testlock.py is running but successfully removes the locked file when testlock.py has been stopped with a Ctrl-C.

Note that this approach works in Windows but it won't work in Unix because, according to the Python documentation:

On Windows, attempting to remove a file that is in use causes an exception to be raised; on Unix, the directory entry is removed but the storage allocated to the file is not made available until the original file is no longer in use.

A platform-independent solution using an additional Python module FileLock is described in Locking a file in Python.

(FURTHER EDIT)

It appears that the OP didn't necessarily want a solution in Python. An alternative would be to do this in bash. Here is testlock.sh:

#!/bin/bash
flock lockfile.lck sequence.sh

The script sequence.sh just runs a time-consuming operation:

#!/bin/bash
for i in `seq 1 1000000`;
do
    echo $i
done

Now, while testlock.sh is running, we can test the lock status using another variant on flock:

$ flock -n lockfile.lck echo "Lock acquired" || echo "Could not acquire lock"
Could not acquire lock

$ flock -n lockfile.lck echo "Lock acquired" || echo "Could not acquire lock"
Could not acquire lock

$ flock -n lockfile.lck echo "Lock acquired" || echo "Could not acquire lock"
Lock acquired

$

The first two attempts to lock the file failed because testlock.sh was still running and so the file was locked. The last attempt succeeded because testlock.sh had finished running.