cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

We are happy to announce the new Windchill Customization board! Learn more.

Windchill installation problem can't join Std out or Std err

SteveLundy
3-Visitor

Windchill installation problem can't join Std out or Std err

Hi all,

I'm rather new to Windchill, and I am attempting to install the Windchill application in a monolithic development environment. I have been having problems with the Solution installer. It only goes so far then it aborts. I found the log file and following is the last operation attempted before the installer abborted:

DEBUG 2014-08-12 09:12:41 - Apache seems to be running.

INFO 2014-08-12 09:12:41 - Running loader command: C:\ptc\Windchill_10.2\Windchill\bin\windchill.exe --java=C:\ptc\Windchill_10.2\Java\bin\java.exe --javaargs=-Dwt.load.installer.serverManagerTimeout=300 wt.load.WindchillLoader -All -Unattended -AbortOnError -IncludeDemo -Locale=en -User=wcadmin -Password=Pearl00

INFO 2014-08-12 09:13:51 - joining with std out thread

WARN 2014-08-12 09:14:21 - std out thread join timed out. std out log may be incomplete.

INFO 2014-08-12 09:14:21 - joining with std error thread

WARN 2014-08-12 09:14:51 - std err join timed out. error log may be incomplete.

FATAL 2014-08-12 09:14:51 - Windchill loader exited with error status = 1

DEBUG 2014-08-12 09:14:51 - Installation is Aborting. The installation cannot continue.

DEBUG 2014-08-12 09:14:51 - Installation is Aborting. The installation cannot continue.

I have been diving through the trouble shooting guides and other documents and I can't seem to find a solution to this issue.

Any assistance would be greatly appreciated.

Regards,

Steve

1 ACCEPTED SOLUTION

Accepted Solutions

Well, that did it. I totally started over from scratch, and this time I went strictly with the defaults for the http and https port numbers.

Another different thing I did this time was that I created the fully qualified DNS Host name in the Hosts file on my VM, rather than attempting to use an IP address instead. (Attempting to use something in a format than my.example.com was what forced me to change the ports in the first place.) Other than that, everything else was the same between both major install attempts.

The first thing I noticed right off, was that this PSI execution did a lot more stuff during the installation process. even before I got to the point where my first attempt failed. For example in the first run, the log file totalled in size around 7-8 megs in size. I checked the log size on this attempt and it was several times larger (roughly 80 megs in size) at roughly the same point in the execution.

In the end, the main problem resulted from not using the fully qualified DNS Host name.

Anyway, thanks for your assistance. Now on to the post installation steps.

Regards,

Steve

View solution in original post

16 REPLIES 16

Steve,

I think that this is most likely an Apache not running/accessible issue (even though it says that it seems to be running in the log).

Now you have an aborted installation, you should have the apache load there on you system - can you start it manually and using a browser get to http://<servername> - you should get an "it works message"?

If not, then investigate your Apache logs as to why apache is not starting / accessible.

If Apache does appear to start and be working OK when tested manually, it would suggest that it is an issue with the PSI not being able to start Apache, or that it can start Apache OK, but the PSI can't reach it to test that it is there.

A possible quick and dirty solution might be to start Apache manually just before it gets to this part of the install.

You could also try running the PSI with Apache already started before running the PSI.

Another thought - I presume that there is not another Apache installation on the machine that might be confusing things with the PSI?

See how you go with that

Rgds

Gary

Hi Gary,

Thank you very much for responding.

One of the first problems I noticed with the PSI was that if the Apache server was running already, the installer would fail quite soon into the install. That means everytime I run the installer, I manually kill the left over Apache server from the last attempt.

That being said, the last time I ran it, watching the log file via baretail, the Apache server started up ok, and I was able to verify it was up using my browser before the error messages occured. Also, the VM I am trying to install on is a brand new VM, and there are no other Apache or IIS servers running on it. (I checked on Services just to be sure)

I'm open to other suggestions.

Thanks agan,

Steve

Steve,

I have seen this sort of thing before when the PSI/Upgrade tool can't see the running installation of Apache due to it being an SSL configuration (although this would be on an existing system, not a new install) - ie Apache is running on SSL port 443 and the PSI is trying to access it on port 80 or vice versa.

I know of no way to do an SSL install of Apache via the PSI at versions up to and including 10.1, but I have never installed 10.2 - presumably this is now not an option at install time in the PSI? If it is now possible to configure https out of the box on installation (I somehow doubt it), then this would be somewhere to look...

Also, are you using standard port 80 for your Apache install, if not there may be some confusion arising as to where the PSI is looking to find your Apache Server?

Do you see an entry in the Apache access logs for when the PSI tries to detect if Apache is running at the part of the install just before it exits - presumably if the PSI is actually able to test access to Apache, you should see something in the Apache logs? This might give you a clue as to where to look.

Rgds

Gary

I presume there is nothing in the PSI installer logs that helps diagnose the issue:

C:\ptc\PSI\installer\logs

Rgds

Gary

Hi Gary,

The last section of the Installer log where the error occurs I posted above in the first message. PTC Support took a complete copy of the log file, in case there is anything else in the previous 7 megs of logs.

Regards,

Steve

I've included a slightly larger log snippet here that I did in my first post. This one includes the startup of the Apache server. It was in the middle of this block where I actually tested the connection myself using my browser.

So yes, I am using non-standard ports for the Apache server, 8001 for http and 8020 for https.

DEBUG 2014-08-13 06:52:43 - apache appears to be down. Starting it...

DEBUG 2014-08-13 06:52:43 - Executing: cmd.exe /C set SystemRoot

DEBUG 2014-08-13 06:52:43 - Executing: cmd.exe /C set SystemRoot

DEBUG 2014-08-13 06:52:44 - Starting Apache with: C:\Windows\system32\cmd.exe /C start "Apache C:\ptc\Windchill_10.2\HTTPServer" /MIN C:\Windows\system32\cmd.exe /C C:\ptc\Windchill_10.2\HTTPServer\bin\httpd.exe -f C:\ptc\Windchill_10.2\HTTPServer\conf\httpd.conf

DEBUG 2014-08-13 06:52:44 - Executing: C:\Windows\system32\cmd.exe /C start Apache C:\ptc\Windchill_10.2\HTTPServer /MIN C:\Windows\system32\cmd.exe /C C:\ptc\Windchill_10.2\HTTPServer\bin\httpd.exe -f C:\ptc\Windchill_10.2\HTTPServer\conf\httpd.conf

DEBUG 2014-08-13 06:52:45 - socket connect to localhost:8001 completed with no error

DEBUG 2014-08-13 06:52:45 - Checking if web service is running...

DEBUG 2014-08-13 06:52:45 - checking URL connection to http://spkwind1:8001 ...

DEBUG 2014-08-13 06:52:45 - apache running at http://spkwind1:8001

DEBUG 2014-08-13 06:52:45 - Apache seems to be running.

INFO 2014-08-13 06:52:45 - Running loader command: C:\ptc\Windchill_10.2\Windchill\bin\windchill.exe --java=C:\ptc\Windchill_10.2\Java\bin\java.exe --javaargs=-Dwt.load.installer.serverManagerTimeout=300 wt.load.WindchillLoader -All -Unattended -AbortOnError -IncludeDemo -Locale=en -User=wcadmin -Password=Pearl00

INFO 2014-08-13 06:53:55 - joining with std out thread

WARN 2014-08-13 06:54:25 - std out thread join timed out. std out log may be incomplete.

INFO 2014-08-13 06:54:25 - joining with std error thread

WARN 2014-08-13 06:54:55 - std err join timed out. error log may be incomplete.

FATAL 2014-08-13 06:54:55 - Windchill loader exited with error status = 1

DEBUG 2014-08-13 06:54:55 - Installation is Aborting. The installation cannot continue.

DEBUG 2014-08-13 06:54:55 - Installation is Aborting. The installation cannot continue.

If I need to change these back to the default values, is there a way to do this without having to re-do the entire installation? If I run through the PSI steps again it will my previous attempts and and force me to input new values.

Regards,

Steve

OK, non-standard ports, so it is bound to be related to this.

"So yes, I am using non-standard ports for the Apache server, 8001 for http and 8020 for https."

How come you are mentioning https at installation time - this would normally configured post installation?

Presumably, at this point (of installation) your Apache is still configured as http and hence the PSI should be looking for a http server on port 8001 - is that correct?

check the site.xconf and psi_ii.xml files for the correct non-standard ports that you are using.

Worst case scenario, install it as port 80 and then change the site.xconf and httpd.conf files to use the non-standard port...

Rgds

Gary

You are sure that there is no https configuration involved here - is that correct?

I can't see it can be if you are doing a fresh install, but thought I should check...

The reason I mention this is because SSL configured systems can cause issues with the PSI JVM not having the servers self-signed SSL certificates (or sometimes the Certificate Authority ca-bundles for "proper" certificates) in it's key stores and hence the PSI cannot connect to the Apache server...

Starting to run out of ideas now...

How about trying the install on standard ports (http / 80) and then reconfiguring it afterwards to your non-standard ports?


Rgds

Gary

The main reason I included the SSL port was because I was prompted for during the install. No other reason really....

In any event, thanks for your time and effort.... I may just have to re-run it from scratch, although I haven't heard anything as of yet out of Support.

Regards,

Steve

Well, that did it. I totally started over from scratch, and this time I went strictly with the defaults for the http and https port numbers.

Another different thing I did this time was that I created the fully qualified DNS Host name in the Hosts file on my VM, rather than attempting to use an IP address instead. (Attempting to use something in a format than my.example.com was what forced me to change the ports in the first place.) Other than that, everything else was the same between both major install attempts.

The first thing I noticed right off, was that this PSI execution did a lot more stuff during the installation process. even before I got to the point where my first attempt failed. For example in the first run, the log file totalled in size around 7-8 megs in size. I checked the log size on this attempt and it was several times larger (roughly 80 megs in size) at roughly the same point in the execution.

In the end, the main problem resulted from not using the fully qualified DNS Host name.

Anyway, thanks for your assistance. Now on to the post installation steps.

Regards,

Steve

Steve,

I am glad a fresh install fixed the issue.

Are you saying that you used an IP address for the server name during the PSI installation rather than a Fully Qualified Domain Name?

If so, I am surprised you got as far as you did...

Rgds

Gary

I think that when the PSI is re-run on a failed install, that when it is run again, it reads some properties from the previously created in the loadpoint's site.xconf file.

This is then what the PSI uses to decide where to check for Apache, so you should check these properties are correct in the site.xconf file

<Property name="wt.webserver.protocol" overridable="true" targetFile="codebase/wt.properties" value="http"/>

<Property name="wt.webserver.port" overridable="true" targetFile="codebase/wt.properties" value="80"/>

Rgds

Gary

On a similar vein - check the C:\ptc\PSI\installer\instreg\ii389c79d6.13f37e76814.-8000\psi_iir.xml file for this value:

<Variable name="WC_PROMPTED.ig.serverAndServletSettings.webServerHttpPort" value="80"/>

This should reflect which port your Apache is running on too.

Rgds

Gary

Gary Mansell wrote:

On a similar vein - check the C:\ptc\PSI\installer\instreg\ii389c79d6.13f37e76814.-8000\psi_iir.xml file for this value:

<Variable name="WC_PROMPTED.ig.serverAndServletSettings.webServerHttpPort" value="80"/>

This should reflect which port your Apache is running on too.

Rgds

Gary

Ok, found this, but the settings were as expected:

<Variable name="WC_PROMPTED.ig.serverAndServletSettings.webServerHostName" value="spkwind1"/>

<Variable name="WC_PROMPTED.ig.serverAndServletSettings.webServerHttpPort" value="8001"/>

<Variable name="WC_PROMPTED.ig.serverAndServletSettings.webServerHttpsPort" value="8020"/>

Regards,

Steve

Gary Mansell wrote:

I think that when the PSI is re-run on a failed install, that when it is run again, it reads some properties from the previously created in the loadpoint's site.xconf file.

This is then what the PSI uses to decide where to check for Apache, so you should check these properties are correct in the site.xconf file

<Property name="wt.webserver.protocol" overridable="true" targetFile="codebase/wt.properties" value="http"/>

<Property name="wt.webserver.port" overridable="true" targetFile="codebase/wt.properties" value="80"/>

Rgds

Gary

There were two site.xconf files in the install directory, one under the Windchill subfolder, and one under the SQLServer subfolder. Neither of these files contained the properties above.

Regards,

Steve

OK - it must only be when you update an existing installation rather than an install that it reads from the site.xconf files then.

In that case, just check the properties in the psi_ii.xml file as previously mentioned.

Top Tags