Killing CGI app from another CGI app: Best Practice?

I’d like to have one Xojo CGI app be able to kill a different running Xojo CGI app. Is there a Best Practice for doing this? I doubt I have root access over at ServerWarp. I’ll check that out if it’s necessary.

If you know the PID of the process you want to kill and have permission as you said. This is what we use to kill processes on our XojoCloud server from another app. There your login started the other app so it has authority to kill it. We do require authentication to run this routine as you wouldn’t want to allow just any user to kill processes on your server.

[code]dim s as Shell

s = new Shell

s.Execute("kill -9 " + lblPID.Text )[/code]

[quote=439767:@Steve Koger]If you know the PID of the process you want to kill and have permission as you said. This is what we use to kill processes on our XojoCloud server from another app. There your login started the other app so it has authority to kill it. We do require authentication to run this routine as you wouldn’t want to allow just any user to kill processes on your server.

[code]dim s as Shell

s = new Shell

s.Execute("kill -9 " + lblPID.Text )[/code][/quote]
Thanks, Steve. Well, this is actually going to be an automated process, where a Tester CGI app polls the Main CGI app and kills the Main CGI app if it receives HTTP status 500.

Perhaps the monitored app could let the monitor know about it’s PID, and send that by IPC.

But can’t the monitored app be killed by its full-path name without knowing its PID?

And I was hoping there might be a Xojo framework way to do this, without having to do use a shell command like kill or pkill. Because I think I’m going to find out I can’t use such commands over at ServerWarp. Haven’t tried yet.

You can’t kill it based on path. I would use the CGI timer trick and simply remove the CGI file so the app kills itself.

Along those lines, I was thinking of just adding another App.Timer to the Main app and have it Self.Quit when detecting status 500 via HTTPSecureSocket. But I thought it would be more advisable to do that with an external app.

Clever but I don’t think it would work. Remember the 500 exists in the first place because the app has become unresponsive. Not dead but not answering hails either. It may not be in a place where it can check itself plus it’s recursive - you are generating sessions that need threads by virtue of hitting yourself. Stack overflow of the worst kind.

Ok. Then my other alternative was to have the Test app check for a 500 status of the Main app, and if found, rename the Main app’s CGI file and wait 10 seconds, and then rename it back. The Main app’s 5-second timer kills the app when it sees no proper CGI file.

We parse the results of the top command to determine the PID.

[code]c = New Shell
c.Execute(“top -b -n 1”)

if c.ErrorCode = 0 Then
top = c.Result
else
top="Error code (top): " + Str(c.ErrorCode)
end[/code]

you probably need to also watch the pid to see the CPU usage time goes up otherwise the process is possibly hung - there but hung