Community
Participate
Working Groups
Build ID: N/A Steps To Reproduce: 1. Install AC or run setconfig from Remote Desktop Session. 2. Verify temp directory name (eg c:\Documents and Settings\Arnold\Local Settigns\Temp\1). 3. Logout and/or reboot such that temp dir in #2 no longer exists. 4. Try to connect to AC - should fail with connection refused. More information: Here are the contents of the servicelog.log: 22:46:33.437000Z File server started listening on port 10005 22:46:33.046000Z Received command for unrecognized interface: iid=org.eclipse.tptp.eventProvider, cmd=listenerAccepted 23:09:17.734000Z Received PUT_FILE command from client 23:09:17.750000Z Received PUT_FILE command from client 23:09:18.796000Z Client compatibility transport layer received an error command: "Unable to Start Process : Directory Not Found" 13:30:38.109000Z Received PUT_FILE command from client 13:30:38.109000Z Received PUT_FILE command from client 13:30:38.187000Z Client compatibility transport layer received an error command: "Unable to Start Process : Directory Not Found"
Entered sizing.
I would recommend documenting this in the "getting_started.html" until a suitable solution is found. SetConfig is java-based and there is no way to know whether the temp directory is from a Remote Desktop session or not. It gets the environment value from System.getPropertt(). We will require SetConfig to be run from non-Remote Desktop session during installation.
Hi, Samson Currently, when a process is being launched, ProcessController uses SYS_TEMP_DIR, LOCAL_AGENT_TEMP_DIR and java/location parameters, which are set during initial configuration. I successfully launched JUnit tests simply removing SYS_TEMP_DIR and LOCAL_AGENT_TEMP_DIR variables and location parameter in the java.exe alias in the serviceconfig.xml. Also the solution could be in using dynamic configuration for the temporary directory (/tmp for Linux and GetTempPath() for Windows). Dinamic configuration could be used if workingDir setting is absent in the serviceconfig.xml. So it seems to resolve the problem it is enough to modify SetConfig and add dynamic configuretion of temp directory.
Hi Joe, Kevin. Does Igor's suggestion (comment #3) sound reasonable? I cannot recall why there is a need for static temp directories. I understand that the temp location may be different depending on the user's environment setting. If the test artifacts are being deployed for every invocation, then having a dynamic, user-defined temp directory may not be a problem. The only problem I can think of is when both the user and the system do not have the TEMP or TMP environment variable defined. Then the static temp values in the config file make sense. Is there a better way of handling this?
This problem seems to happen frequently and causes a lot of headaches. We already know how to work around it with serviceconfig.xml or setconfig. What we need is for the agent controller to not depend on potentially fleeting temp directories.
Any suggestion on how to solve this? If the TEMP value is hard-coded in the config file during SetConfig, we can create that directory if it does not exist in the current session.
I am proposing a fix like this: 1. Change the "SYS_TEMP_DIR" to "%TEMP%" inside "serviceconfig.xml" 2. On Windows the "TEMP" environment should be already defined 3. On Linux, we need to edit "./ACStart.sh" to check if "TEMP" is defined. If not, defined it as "/tmp" before starting "ACServer" The "ACStart.sh" script will need the following lines before starting the "ACServer" executable: if [ x$TEMP == x ]; then export TEMP=/tmp fi I have tested the above with TPTP JUnit and it seems to work fine. Any objection?
The fix will be implemented as follow: 1. AC's "serviceconfig.xml" file will have its "SYS_TEMP_DIR" set to "%TEMP%" to pick up whatever is defined in the user environment. 2. AC will check if TEMP is set and points to a valid directory. If not, the AC will not start and log an error in the "servicelog.log" file. If ran as a console application, it will print the error to stdout as well. If ran as as Windows service, the "servicelog.log" is the only place where the error is logged but a Windows Service Error Dialog will be popped up. 3. Linux's "ACStart.sh" will be updated to check if "TEMP" is defined. If not it will set it to "/tmp". It is up the the AC to check if this directory is valid.
Fix checked into CVS 2007/05/04 22:26 EDT.
Samson, on Linux, you have to also include the following in ACstop.sh: if [ x$TEMP == x ]; then export TEMP=/tmp fi If the $TEMP varialble is not defined at the time the user runs ACStop.sh then they're presented with the following error message and AC is not terminated: "The TEMP environment variable does not point to a valid direcotry." Adding the above snippet to ACStop.sh will stop AC and get rid of the error message. I'm reopening this defect and raising its severity since it introduces problems with IAC in Linux.
Created attachment 66502 [details] ACStop.sh
Hi Navid. Can you review the attached ACStop.sh? I will request for approval after this is reviewed. Thanks.
Looks good to me.
Fix approved and checked into CVS 207/05/09 15:11 EDT.
This appears to cause 187062 on 64bit platforms. I posted details there about what I think needs to happen to fix it.
Created attachment 72172 [details] 4.2.2 patch #1
Created attachment 72173 [details] 4.2.2 patch #1 config.jar This "config.jar" replaces the AC's "lib/config.jar".
Created attachment 72174 [details] 4.2.2 patch #1 RAStart.sh Linux only: This "RAStart.sh" replaces the AC's "bin/RAStart.sh"
I have validated that the patch config.jar fixes the problem.
On Ubuntu 7.04 (feisty), I had to change ACStart.sh et al. to if [ "$TEMP" = "" ]; then export TEMP=/tmp fi Otherwise they would complain about ==.
Created attachment 77057 [details] 4.2.2 patch #1 config.jar This one is rebuilt with IBM JDK 1.4.2 SR8.
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.
