Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much

Kill Processes on Pre-Forking Servers

by aijin (Monk)
on Oct 24, 2001 at 00:24 UTC ( #120894=perlquestion: print w/replies, xml ) Need Help??
aijin has asked for the wisdom of the Perl Monks concerning the following question:

I've been working on a server based on the pre-forking server in recipe 17.12. I've come across a problem for which I'm having trouble seeing a solution.

The server is sent client requests through a web-browser. That part works perfectly. What I need to be able to do is send the server a client request to kill another process.

What's the problem? Well, if I allow a maximum of 5 processes to be forked at a time, and all 5 are busy processng requests, then the request to kill will be waiting in the queue and not killing the process immediately. If there was a guarantee that the processes would end quickly, this wouldn't be an issue, but the server handles requests that can take hours to complete. Waiting several hours for a kill request to be processed just isn't good enough.

I can't kill the process direct from the web-page, as I found out in another node.

I know I could just write another program owned by root which could kill the processes, but I, and The Guy Who Reviews My Code agree that it would not be the most elegant solution.

I, gentle monks, am stuck. I've been wracking my brain all day and I can not see a solution. Perhaps I am too close to the problem. I throw myself on the mercy of the Monastery. Help a fellow monk in need!


Replies are listed 'Best First'.
Re: Kill Processes on Pre-Forking Servers
by {NULE} (Hermit) on Oct 24, 2001 at 00:59 UTC

    Can you test and if five processes are forked and running fork instead to a sixth special process that only handles killing the requests? I don't have whatever book recipe 17.12 happens to be from :) so I may be completely off base. If the kiddies are pre-forked perhaps you could fork an extra just to have a spare available to kill the request and as part of the IPC from the server pass the number of active children and their tasks. Alternatively you could design the IPC structures to be very explicit about the expectations of how long the process should take or at least when the child should check back in.

    To be more specific here what I mean is that as part of the IPC something I like to do is pass to the child a time limit within which I must have a response waiting for me. Basically the parent says "I'm checking back in 20 seconds so be done by then." At that point you could implement an alarm() inside an eval in the client or if you have fairly tight loops in your kiddies, you could regularly check the elapsed time. If the time elapses return to the server either "I'm still busy, when should I check back again?" or "Error! Couldn't finish in X seconds." Er, whatever, you get the idea. You would probably want the parent to check for the childs response within its own set of eval and alarm blocks so that in case of problems the parent won't hang indefinitely waiting for a reply. (I hope you are on a system with a working alarm!)

    I guess my point is that carefully structuring the IPC communication might be able to solve your problems. An example (perhaps overly simple) of how I struggled with this is in my Curses Chatterbox Client. This only has one child so the IPC may be much simplier than what you require, but it might give you ideas.

    This kind of stuff is exciting to me, so I would love to see some code or hear your ideas on how you attack this (particularly if you win! :) I'd also like to see what 17.12 is so if anyone has a link to that or something like it, I'd be interested. Thanks!

    Good luck, and I hope I'm not totally off base here,
    After reading the other thread (belatedly) that was referenced in your post, I disagree with your comment that you "can't kill the process direct from the web page". The gist of that post is that the owner of a process can kill the process. Even if the server is running as user nobody it should certainly have the ability to terminate its children with a kill, of course I haven't tried it, but it stands to reason. If that approach does what you desire I would give it a shot. I feel silly for not pointing that out sooner.

      I believe the 17.12 reference is from the O'Reilly Perl Cookbook. Pre-Forking Servers.


      "Make everything as simple as possible, but not simpler." -- Albert Einstein

Re: Kill Processes on Pre-Forking Servers
by chipmunk (Parson) on Oct 24, 2001 at 01:29 UTC
    How about running a separate web server on the same machine, just to the kill requests? You could set up this web server to only accept requests for the specific script or directory for the kill script. As long as both servers run as the same user, I don't think there should be any problem for the second server to kill processes of the first server.

    I don't know how you have the kill script set up currently; maybe it just kills jobs running under the same server. With the proposed second server, the kill script could present a list of all the jobs running on the first server. You'd pick the jobs you want killed, submit the form back to the script, and the script would just kill those jobs.

Re: Kill Processes on Pre-Forking Servers
by shotgunefx (Parson) on Oct 24, 2001 at 02:46 UTC
    One thought would be to have a multi homed server (covered in chapter 17 as well in the Cookbook) . Use one ip for the regular tasks and one for admin functions like killing processes.


    "To be civilized is to deny one's nature."
      It's strange how, when one has walked away from a problem and done something different for a few hours, how solutions pop into one's head.

      Last night, around midnight, while taking a shower it occurred to me that I might be able to have a port that just accepts kill requests on the server...and lo and behold, a similar solution is posted here when I get to work.

      Thanks to all of you. I think I can best this beast now. :)


Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://120894]
Approved by root
[Discipulus]: I bet and.. I won!! ;=)
[Corion]: Discipulus: Yes, very good spot!

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (9)
As of 2018-05-25 15:38 GMT
Find Nodes?
    Voting Booth?