nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

OpenAPI server is not running (apparently)

mike_s

I have a problem whereby I cannot access TeamSite via the GUI.

iwserver is running so I can access everthing from the command line OK.

I get 404 errors which I think is because the servlet engine is not running.

When I run iwreset -ui I get the following message:

ERROR: Failed to start Interwoven Servlet Engine. OpenAPI server is not running.

This message is sent by iwtcboot following an attempt to access the service using the IWAccessService in the openapi_client.jar that returns a non-zero code (which it does - 21, in case anyone reading this knows what that return code means).

Any ideas anyone?

Find more posts tagged with

Comments

nipper

Restart TeamSite. See if that takes care of it. We have seen that before where openapi would not come up cleanly
before.

If restart does not work, start checking logs, and check what port openapi is to hang on.

Are you unix or dos ? You can also use netstat to check out if it is really hanging on that port.

Andy

Migrateduser

I have seen issues with attempting to use the GUI before all the TS processes have come up, including openapi. Does this error occur the first time you attempt to access TeamSite after a reboot? How long did you wait before you attempted a login?

What version of TeamSite (including SP level)?

lissa

bturns

I just posted a response to this in your other posting. Here it is again

=================================

I think you might be facing a problem that we've had in the past. That is when an iwreset -ui is performed some of the java process (possibly OpenAPI) fail to stop. This in turn prevents OpenAPI and Tomcat from restarting. Usually when we get this error we have to run

# iwserver stop_all

sometimes this is sufficient. However, we will then run

# ps -ef | grep java

and see if all the java processes have stopped. Namely: /usr/iw-home/tools/java1.3/bin/../bin/sparc/native_threads/java -server -Xbatch

If they haven't stopped we'll kill the remaining processes and then start TeamSite.

This usually does the trick.

Brian

mike_s

I have tried stop_all already, plus I've re-booted the box, all to no avail - but thank-you for your posts and any other suggestions would be appreciated.

One thing that I suspect might have something to do with it (although I don't see why) is that in the following entries appear in iw-home/AdminServer/servletd/logs/servletout.log:

iwtcboot: ---------- STOPPING: Friday March 26 15:15:54 GMT 2004
Using classpath: /usr/iw-home/AdminServer/servletd/lib/ant.jar:/usr/iw-home/AdminServer/servletd/lib/iw-xerces.jar:/usr/iw-home/AdminServer/servletd/lib/iwwebapp.jar:/usr/iw-home/AdminServer/servletd/lib/jasper.jar:/usr/iw-home/AdminServer/servletd/lib/jaxp.jar:/usr/iw-home/AdminServer/servletd/lib/parser.jar:/usr/iw-home/AdminServer/servletd/lib/servlet.jar:/usr/iw-home/AdminServer/servletd/lib/webserver.jar:/usr/iw-home/AdminServer/servletd/java1.3/lib/tools.jar
Stop tomcat
java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:320)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:133)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:120)
at java.net.Socket.<init>(Socket.java:273)
at java.net.Socket.<init>(Socket.java:100)
at org.apache.tomcat.task.StopTomcat.execute(StopTomcat.java:104)
at org.apache.tomcat.startup.Tomcat.stopTomcat(Tomcat.java:267)
at org.apache.tomcat.startup.Tomcat.execute(Tomcat.java:174)
at org.apache.tomcat.startup.Tomcat.main(Tomcat.java:235)
iwtcboot: ---------- STARTING: Friday March 26 15:16:00 GMT 2004

which suggests that an error occurs when stopping the servlet daemon, although no error occurs when re-starting.

mike_s

(thought I'd already replied to this so it might appear twice)

The version/sp is 5.5.2 SP4.

This does not just appear following a re-boot but has only just started happening - possibly as a result of running iw-home/install/install_webapps.ipl -c.

diago

did you modify the hostname ?
I have this problem when I correct the /etc/hosts file of the machine
the configuration file openapi.cfg doesn't mach /etc/hosts any more and openapi fails to start
I have to modify openapi.cfg by hand

regard,
Eric Grandjean

mike_s

No, the hosts file hasn't changed.

I think the original title of this post is a bit misleading as it would seem that openAPI is running but servletd thinks it isn't when iwreset -ui executed.

The openAPI process exists - when I do 'ps -ef -o user,args | grep java' I get the following results:

iwui /usr/iw-home/tools/java1.3/bin/../bin/sparc/native_threads/java -server -Xbatch

which I understand to be the openAPI service. I suppose this could just be a process that has failed to end normally. The servletd command doesn't seem to notice there is a problem, as to all extent and purposes it's logged as started when doing iw.server start. However, when doing iwreset -ui, iwtcboot first checks the service is running via the IWAccessService class. This class returns an error code of 21 and as iwtcboot considers anything but 0 to mean that openAPI is not running it logs it as such. What might help get to the bottom of this is if I knew what the error code 21 meant.

Adam Stoller

On my TS6.0L solaris server - 'ps -ef | grep openapi' shows:
iwui 29630 [...] iwopenapi -server -Xss4000000 -Djava.library.path=/apps/iw-home/iwopenapi -Djav

On my TS5.5.2 SP2b solaris server - 'ps -ef | grep openapi' shows only the 'grep' process - instead, I find it easier to use:
/usr/ucb/ps axwww | grep openapi
You might try that - just to make sure that the java process you're looking at is in fact OpenAPI and not something else.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

mike_s

Thanks, that's helpful as it confirms that the process I thought was the openAPI process (but wasn't completely sure about) is in fact the openAPI process. When I run '/usr/ucb/ps axwww | grep openapi' I get the following:

10668 ? S 0:06 /usr/iw-home/tools/java1.3/bin/../bin/sparc/native_threads/java -server -Xbatch -Xss2m -Djava.rmi.server.codebase=file:////usr/iw-home/iwopenapi/openapi_client.jar -Djava.security.policy=file:////usr/iw-home/iwopenapi/openapi.policy -Djava.library.path=/usr/iw-home/iwopenapi -Dtomcat.home=/usr/iw-home/servletd org.apache.tomcat.startup.Tomcat
11235 pts/1 S 0:00 grep openapi

Out of interest, how is this different from the normal 'ps' command I have been using?

mike_s

I've just realised that this looks very much like the command used to start the servlet daemon which starts openAPI as part of its invocation (or so I believe). But that doesn't necessarily mean that openAPI is running, or does it?

Adam Stoller

Solaris uses a System-V / POSIX flavor of the 'ps' command by default - which has a specific set of flags and output.

/usr/ucb/ps is the U.C. Berkeley version of 'ps' (associated with BSD Unix rather than System-V / POSIX) and has a different set of flags and produces slightly different output.

Some versions of Unix (AIX used to - not sure if it still does) provide a hybrid - in which if the flags are preceeded by a '-' it treats it as the SysV command, and if they aren't preceded by '-' it treats it as the BSD command.

http://www.rt.com/man/ps.1.html does a decent job of showing the manual page for the hybrid variety of the utility.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

ts_user

Mike were you able to solve the problem? We are facing similar problem though we are on windows TS 5.5.2 SP3. The problem started appearing after we installed Opendeploy 5.6 SP1(we liked and were stuck to OD 4.5 till now due to a lot of customization we were reluctant to give up). The problem appears after each reboot and looks like a contention problem in starting OpenAPI/rmi registry. What we found was that stopping Opendeploy service resolves the problem with users able to use TeamSite GUI. Restarting Opendeploy service after users are able to log in does not affect the already started processes. Check if you are listening to 1099 port and the errors you see in local/logs/iwui/servletd_err.log file when you have the problem.

mike_s

No, we haven't resolved the problem yet. We now have a support case open so hopefully this will lead to a solution. It does look like it could be an RMI issue although there is no contention issue as far as we can see. Thanks for your comments.

mike_s

For the benefit of others who might experience the same problem we now have a solution.

The problem started when I re-compiled the webapps. This was because root, the profile I was logged on as when I did the re-compile, had an incorrect umask setting. It was set to 0007 when it should have been 0022. Once this had been changed it was simply a case of performing the following steps (while logged on as root, of course):

1) issue iw.server stop_all to stop all TeamSite services and the RMI registry process
2) stop OpenDeploy Admin server and OpenDeploy (iwtcboot stop and iwod stop)
3) Verify that RMI registry is stopped (netstat -a | grep 1099)
4) Verify that all iw processes ended (ps -ef | grep iw) and killing off any that remained (none, in our case)
5) Backup the webapps directory (optional)
6) Run "iw-home/install/install_webapps.ipl -i -f" to force deletion of webapps and reinstall webapps, checking the messages to ensure the WAR files were expanded correctly
7) Re-start TeamSite (iw.server start)
8) Re-start OD and OD Admin (if not started by iw.server start)
9) Run iwreset -ui if anything didn't come up (not required in our case)

Easy when you know how Smiley Wink