Community
Participate
Working Groups
As a RAC/piAgent developer using shared machine resources, sometimes I find there is a RAC running on a machine that I'd like to kill so I can start my own. For example, the RAC might have been started by another user, and I want to start one as myself. If I don't have permission to kill processes started by other users, I am not able to do this. Even though I don't have enough permission on the target machine to kill a process, I *do* have enough permission to connect to the RAC from the Workbench. So if there were a Workbench command to kill the RAC, I could use that. This would mean creating a new RAC command telling it to exit, and also a Workbench UI change to expose that command - probably in the same dialog that lets me test the connection to a machine's RAC. This would help developers who are testing on shared machines.
update based on requirements group review
Alan, we discussed this in our team recently. The consensus is that this could lead to unintended security issues if RAC can be killed by any workbench. Isn't it more proper to get administrator (superuser) userid/password on that machine in order to kill the process? I am in favour of returning this enhancement request.
I do not agree. There are plenty of security issues in the RAC, and I don't think this one tips the balance. The open-source RAC is not a secure service and it is not hardened against denial-of-service or other attacks. While it would be rude and unprofessional for a user to kill a RAC while others are using it, that's not a reason to stop considering this feature. During the Hyades 3.x development cycles, the inability to kill another user's RAC was a significant problem. There are shared development resources (especially on iSeries and zSeries) where superuser access is not available. If a developer in Toronto starts a RAC and then goes home for the night without killing it, that means developers in California lose half a day of access to that machine for their own testing. Remember, with today's implementation you have to restart the RAC even if all you want to do is change an agent's configuration setting. (There is a requirement for TPTP 4.0 to improve this, but I don't expect it to change for 3.3.) We could make this a configuration option. I would want it to default to "Remote kill is allowed." A concerned user could change serviceconfig.xml to change it to "not allowed." Otherwise we'll suffer when developers forget to change the setting after installing a new RAC build for testing. I don't care if the mechanism for killing a RAC remotely is not exposed in the UI. For example, we could put a Java program into the CVS repository which opens the pipe to a RAC and sends the kill command. That program doesn't have to be part of any published build. A user who wanted to kill somebody else's RAC could check out the program, compile it, and run it, supplying arguments for the host name and port number. By doing something like this, we're not exposing the capability to ordinary users, only to developers.
Now that we have a "3.3" Version in bugzilla, updating bugzillas targeted to 3.3 or a 3.3 iteration so that their Version matches their Target. "future", "unspecified", "4.0", and "4.1" Versions will not be updated.
Enhancement checked into CVS (3.3 and 4.0). Usage: RAServer -shutdown This will create a 8 byte message "SHUTDOWN" and send it to the RAC through its master named pipe. On the RAC side, once we've received this message, we shut down the RAC calling "ra_stopServer()", just as if we have send a SIGINT to it. Note: need additional test on iSeries after this fix is picked up by the build since the way to start RAServer is different on that platform.
The iSeries command may look like the following: CALL PGM(HYADESDC/RASERVER) PARM('-shutdown')
Fix checked into CVS (3.3 and 4.0) on 2005/04/01 13:30 EST.
As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant enhancements/defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement/defect is verified/closed by the Project Lead since this enhancement/defect has been resolved and unverified for more than 1 year and considered to be fixed. If this enhancement/defect is still unresolved and reproducible in the latest TPTP release (http://www.eclipse.org/tptp/home/downloads/), please re-open.
