Shell script for Apache stop (kill command)

[tash S]

Hi All,

We have the program kill [process number] and kill -p [process number] on HP-UX 11i and the Apache process is alive more than 10 seconds. A user saw the message like "Cannot stop Administration Server. Please kill process $hpid manually and try again."

We are using 1.3.19-rev2 of Apache.

Here is the extraction from our shell script.

----------------
pidfile="./WebServer/logs/httpd.pid"

if ($ps | grep "$hpid" >/dev/null) ; then kill $hpid ; sleep 10 ; else rm -f ./
WebServer/logs/httpd.pid ; fi
# try again with more force
if ($ps | grep "$hpid" >/dev/null) ; then kill -9 $hpid ; sleep 10 ; else rm -f
./WebServer/logs/httpd.pid ; fi
# give up.
if ($ps | grep "$hpid" >/dev/null)
then
echo
echo Cannot stop Administration Server. Please kill process $hpid manually and try again.
---------------

We can reproduce the issue on good spec machine like (2CPU, 8GB RRAM) , but we can not reproduce 1CUP machine

If those kind of error was barely happening on n good spec machine but we can not see the phenomenon on 1 CPU machine.

Regards,

[Bill Hassell]

The script fragment is incomplete and several variables are undefined. Is $ps the ps command? Is $hpid a process ID number? If so, using grep is a serious error in trying to locate a process. grep knows nothing about PID -- it is a dumb match program. If the $hpid is 123 then grep will find PID=1234 and also 4123 and on and on. It will also find bill123 which is a user on the system and possible lab123b which is a group name. Never use grep for finding a PID. Just use ps to find the process by PID:

ps -p $hpid

will be an exact match. Using grep almost always results in multiple (and unexpected) matches. You may end up killing important processes or finding a process which is not the right one.

[Steven Schweda]

According to:

http://httpd.apache.org/docs/
http://httpd.apache.org/docs/1.3/
http://httpd.apache.org/docs/1.3/stopping.html

Apache 1.3 comes with an "apachectl" script:

http://httpd.apache.org/docs/1.3/programs/apachectl.html

Is there any reason not to use that one?

It's hard to know what's wrong in your case
when we can't see what your "$ps" is, or what
is in its output. As Mr. Hassell has
explained, "grep" for a process ID is almost
always a bad idea. Which is probably why
Apache saves its own PID in its "PidFile":

http://httpd.apache.org/docs/1.3/mod/core.html#pidfile

I run Apache on VMS where things are done
differently, but I'd expect "apachectl" to
be written better than your script appears
to be.

[tash S]

Hi All,


We got the pidfile in the below.

pidfile="./webserver/logs/httpd.pid"

I do not use egrep. For some reson, I do not use apachectl.

The question is that the time of the process to be killed 'kill -9 command' depends on the number of CPU or patch level?

[Steven Schweda]

> The question is [...]

No, the question (or, at least _one_
question) is what your "grep" command is
finding in the "$ps" output. It's not
unusual to find the "grep" process itself, as
well as the process with the PID for which
you are looking. If you try to kill the
"grep" process instead of the Apache process,
you may not get the result you want.

Whether the "$ps" sees the "grep" process
will depend on when the processes are
created, and how fast they run, and _those_
things may depend on the number of CPU's or
the patch level, or any number of other
things.

This is why so many people will tell you not
to use "grep $pid" to find a process.

> For some reson, I do not use apachectl.

Until you figure out what that reason might
be, I'd suggest using "apachectl", or, at the
very least, looking at it to see how it
works. I have not looked at it, but if it
uses "grep" to look for a PID in "ps" output,
I'll be amazed.

[Ralph Grothe]

As you seemingly are storing the PID of the httpd parent process, which needs to be signalled, in a pidfile then you should use it.
However, I would urge you to use an absolute path, not a relative one as you did:

pidfile="./webserver/logs/httpd.pid"

Then you could test if the httpd root process is running like so:


httpd_pid=$(cat $pidfile)

if [[ -n $httpd_pid ]]; then
if kill -0 $httpd_pid 2>/dev/null; then
# do the shutdown
# use better method than mere kill
kill $httpd_pid
else
echo "No Apache running"
exit 1
fi
else
echo "pidfile contained no PID"
# implement other PID parsing here
# (see below)
fi



However I would suggest to use the shipped apachectl script.
Usually it only requires minor adaptations (if any at all), but mostly only for getting the status argument work (requires enabling mod_status in apache, and a command line user agent that can dump the HTTP response as ordinary text).

If you absolutely have no penchant to use apachectl then you could parse the httpd parent proc's PID like this (only works this way on HP-UX, and if you don't have several separate webservers running)

httpd_pid=$(UNIX95= ps -C httpd -o pid= -o ppid=|awk '$2==1{print$1}')

[Tor-Arne Nostdal]

Hi,
As mentioned "apachectl stop" should be used if you intend to stop the apache server.

... but if you intend to stop a specific process you might be interested in looking into the /sbin/init.d/template script and how it is done by the init process.

You could use the killproc function, but as Clay wisely have stated!!! You must ensure a unique identification of you process

/Tor-Arne

[tash S]

The question itself of mine was NOT the matter of the script.

The question is why the time of the process to be killed 'kill -9 command' take a time, for example, more than 10 seconds, depends on the number of CPU or patch level?

1 CPU case was very fast.
4 CPU case was that very barely it takes more than 10 seconds.

Thanks,

[Steven Schweda]

> The question itself of mine was NOT the
> matter of the script.

Perhaps not, but the script is so badly
written (and described) that no one can tell
exactly what it is doing. Perhaps the first
'kill $hpid' works perfectly, but the second
'$ps | grep "$hpid"' gets lucky and finds the
string "$hpid" somewhere else in the report.

For example, if "hpid" were "123", and some
user were running a program named
"abc123def", then the second "$ps" (whatever
that might be) report could include the
"abc123def" job, and 'grep "$hpid"' could
find _that_ "123" even if process "123" were
dead and gone.

It looks like a bad script, and you have not
explained all of its mysteries (like "$ps",
or "$hpid"). It could do anything. No one
can tell you _why_ it does anything, because
no one can know _what_ it is doing.

I have a program which adds two numbers
together, but it gets the wrong result. When
you can tell me what's wrong with my program,
I'll tell you what's wrong with yours.