UNIX for Advanced & Expert Users

Assume I spawn a process on (csh) command line, like

Code:

> du -a / >& /dev/null &

which creates a process with id 1234. Now, I can suspend/resume that process with

Code:

> kill -STOP 1234
> kill -CONT 1234

and can query the process state via 'jobs' or 'ps. How can I though query that state programatically (UNIX/POSIX system, no /proc/ available)?

The only call closest to the problem seems waitpid(), which can use WUNTRACED to get notifications on some signals, including SIGSTOP. That seems to work only for processes spawned within the same application - so I would not be able to write a tool which, for the example above, works like

Code:

> check_proc_state -p 1234
 1234 is Running

Another option is to do something like

Code:

FILE* fd = popen ("ps -ewwo pid=,uid=,state=,command=", "r");

and to grep the output - but ps output is not well standardized (well, it actually is, see ps, but the various implementations do not necessarily adhere to the spec), and also this seems a very cumbersome way to do that. Not to speak of performance...

Any better ideas? The solution ideally should work on MacOS, BSD, Linux, and AIX.

Thanks, Andre.


PS.: yes, I grep'ed the forum: huge amount of related posts, and I may well have missed relevant discussions in the noise. My apologies, and thanks for any pointers...

Hello Andre,

The two ideas that come to my mind:

1) You create a process responsible for spawing your applications to monitor. That way, you create the parent-child relationship that you need for using waitpaid() with the options WUNTRACED and WCONTINUED.

2) You use the appropriate popen("ps...") code depending on which platform you are running. This can be achieved using old plain #ifdef, or using a strategy pattern.

HTH,
Loïc.

Hi Loic, thanks for your answer!

Alas, this is not a viable option in my use case: I have no control over the original parent, nor over spawning process. Well, in those cases where I do have that control, waitpid works nicely of course. The other cases (no control) cause the headache ;-)

That is what I do right now, but its ugly, and broken. For example:

Code:

> sleep 1000 &

> ps -ewwo pid=,uid=,state=,command= | grep 1000
16027   501 S    sleep 1000

> fg
sleep 1000
^Z
[1]  + 16027 Suspended                     sleep 1000

> ps -ewwo pid=,uid=,state=,command= | grep 1000
16027   501 S    sleep 1000

So, the process 'sleep' is active in the first case, and suspended in the second. PS reports the same state - I have no means to distinguish. This seems to be valid for all apps which are sleeping or blocking in any way (which are many in our environment, mostly waiting for IO).

FWIW: the above is on MacOS.

Best, Andre

Hi Andre,

weird. From my understanding, this should be in state 'T' (other OSes report this). I am afraid that you have to resort a MAC specific way for this problem... And as a corollary, likely ask a MAC specific Forum. I am afraid, I can't help further (I don't have yet a MAC at home yet. This is one of my future plan )

Cheers,
Loïc.

Don't get one - its not worth the trouble. Things one a Mac are always *slightly* different than you would expect... :-P

Thanks anyway,

Andre.

If you are using Mac OS X you can use launchd, and then use launchctl to control it, load it, unload it, etc.

Hi,

your comment finally got me to read the launchd/launchctrl man pages ;-) Interesting, but very much non-portable, and non-API solution to the problem. Also, no suspend/resume AFAICS.

Thanks anyway!

Andre.