Ps command and apache

A

Abstract

Hi Everyone

I like to use the ps command to check if some processes are still running of script requests handled by apache. I notice after the execution of these requests the processes will still show in the output for more then 20 seconds.

executed:
Code: 
ps -p 53770 | grep 53770

output:
Code: 
53770  ??  S      0:05.71 /usr/sbin/httpd -k start -DSSL

As long as the request runs the running time is changed. As soon as the request is finished the running time stops. All fine so far. However the process keeps showing in this list for a while, but the execution is finished. Why is that?

As newbie I would think after execution of the request the process has come to an end and is terminate. Therefor it should also be removed from the ps command output as its no longer a process. Why does it stay there after there execution? Were is the mistake in my thinking pattern?

Thanks Abstract
 
Depending on how you have apache configured, it generally has a worker pool that it will broker requests to. As a result, it doesn't fork a process for each and every request. That would be expensive and inefficient. Essentially, it reuses the workers as much as possible.
 
Hi Gordon,

So depending on the apache configuration it could be that a request is handle by a fork which has its own process ID for example 53770.
When the request is executed the fork is just waiting for a new request which means the process ID 53770 is exactly not telling much
about the request but more about the fork which handles the request?

If that's the case is there also a way to find out if a request handled by the apache is still active or already terminated?
 
I think there is an extended server status page that might give you that info. I'm also pretty sure that nothing will hit the apache log until *after* the file has been served.
 
Abstract said:
If that's the case is there also a way to find out if a request handled by the apache is still active or already terminated?
Click to expand...
I think you can check it via sockstat(tracking connected tcp80), but in case 'keepalive' requests you cant track them.
Btw, why you need this?
 
Thank you for all the suggestions. I'm going to read a little bit more about it.

I'm a programmer working on one of my software project which is written in php. I need to have one or several script(s) running in the background continuously to synchronize data. I can run a script(s) continuously which isn't the problem. However I need to know if the process is still running and otherwise it needs to start again. On the current test environment it runs smoothly now.

Because it's essential to have all the data from the master database available to one or multiple slave database(s) in real time it needs to check continuously if records are changed. This is how it looks now:

- One script runs in the background checking with 'ps' command if the running proces(ses) are still alive. If not it starts up
the ones that are needed. This script terminates afer 59 seconds and a crontab will start a new process again
- The synchronize scripts runs with out an execution limit. It's registering in the database the process ids, running time
, status, etc.

Because database registration of the process isn't ultimate proof the process is terminated I used the ps command.
On the current freebsd server I can determine if the process is running or terminated by ps. However for the production version I need to test this on linux, different configurations and servers with much more traffic. So I'll certainly look into smoothing and improving this process. Hopefully finding better way's to do this
 
Hi Everyone,

I solved the problem for now. For the people who are also looking for a solution to this I used the directory /proc/ to determine if the process is still running. [processId] is replaced by the PID of the process:

if [ -d "/proc/[processId]" ]; then echo "running"; fi

It will return "running" when the process is still active. It can easily put into a php script as long as you may execute shell commands.
 
You must log in or register to reply here.
Back
Top