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; } } }

Open Deploy 5.01 problem over Unix Reboot

bscott1

Hopefully someone in this forum has seen this before.. I have experienced and issue with one webserver running iPlanet and Solaris 8 and Open Deploy 5.01 receiver. This server is doing something really strange over a reboot. When the server is rebooted the Open Deploy process gives the error:

message: SESSION_LISTENER_BIND_FAILED
Details: Session Listener failed binding on [1x.8x.xx.1 :20014]
(I put x's in place of the IP)

Then the IWServiceServer.lax is turned into a zero byte file. Huh??? This is really weird and it is only happening on one webserver out of a network of 10 servers (both app and web) What I am not understanding is that over a reboot if Open Deploy has issues connecting to a port why is it changing it's internal *.lax file to zero bytes? What in the Interwoven code is doing this and why? Does anyone have any ideas?

Find more posts tagged with

Comments

bscott1

I figured out a portion of my problem. There were two scripts executed at start-up one was using up the 20014 process so the other was giving the java error with the port conflict. I still have the question about the Open Deploy Code and why it was creating a zero byte file. Does anyone know why this may have happened?

ChuckM

It looks like I might be experiencing the same issue. Were you ever able to find a solution to your problem?

bscott1

Yes. My issue was related to 2 scripts existing in the same UNIX /etc/rc3.d directory (this is where the Open Deploy startup script exists). I had a script written by a Sys Admin as well as the script that Open Deploy automatically installs when you do the install. Make sure your Open Deploy installation is only starting once and the problem shouldn't occur. The zero byte result on the .lax file I never figured out but I believe it just has to do with some internal proprietary Interwoven code (since I removed the secondary startup script it hasn't happened again).