LMS 3.0 Solaris 9 install Mutex error

Unanswered Question
Apr 7th, 2008


I am getting several Mutex error messages on the LMS 3.0 Postinstall packages installation on a Solaris 9.

I have stopped the installation and will remove and try to reinstall.

Memory is 4 GB and Swap 8 GB.

The environment is a Domain on a Sun Server:

[email protected] # uname -a

SunOS cisprd01 5.9 Generic_122300-21 sun4u sparc SUNW,Sun-Fire-15000

Attached is an excerpt of the installation log.

Any help is appreciated

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Joe Clarke Mon, 04/07/2008 - 11:47

Solaris domains and zones are not yet supported. you will need to install LMS directly on the physical server.

rgomes Mon, 04/07/2008 - 12:48

Hi Clarke

Do you think that the Mutex errors are due to running on a Sol 9 domain?

I am reinstalling and will let it run till the end.

Do you know when support for Sol domain will be available?


Joe Clarke Mon, 04/07/2008 - 13:05

It's certainly possible. I am not aware of anyone else seeing this error when installing on a physical Solaris 9 instance.

Solaris container support may be available in the summer release (and probably only for Solaris 10 zones). I haven't heard of any final plans, though.

rgomes Mon, 04/07/2008 - 13:13

Hi Clarke

Thanks for the information.

Just one more doubt, I always read on docs the statement about LMS not being supported on 64-bit native systems. Does it holds true also for Solaris machines? Remember that most Sun Boxes are 64-bit machines.

Joe Clarke Mon, 04/07/2008 - 13:32

LMS is fully supported on 64-bit Solaris, but our executables are only 32-bit, so you will still need the 32-bit compat libs. We only recently added support for 64-bit Windows on LMS 3.0.1.

rgomes Mon, 04/07/2008 - 14:24

Hi Clarke

I think when you install 64 bit Solaris it loads also the 32 bit libs.

Meanwhile I changed the default Localization on Solaris from US.ISO8859-15 to US.ISO8859-1

and the Mutex errors did not showed up.

So far the installation is going OK

Hope it finishes and be operational.

It will be difficult to have a stand alone machine for this customer.

If everything goes well, tomorrow I will try to load UPD 3.0.1 and let you know about.

Joe Clarke Mon, 04/07/2008 - 14:50

Yes, loading Solaris loads a 64-bit kernel with 64-bit and 32-bit libraries by default. While your installation may proceed, and while it way work when it's installed, TAC will offer no support on this configuration. You might want to weigh that against building a standalone server.

rgomes Mon, 04/07/2008 - 16:54


The installation gone OK, all procces are running, I can stop and restart them, but can not web connect to the server.

Any hint ?

I suspect of the environment of the casuser:


How casuser get the proper $path?

I saw the files /opt/CSCOpx/etc/install.profile and .login. Do we need to copy them to somewhere?

I snooped the machine, the packets are getting there:

xyz.corp.net -> cisprd01 TCP D=1741 S=2164 Syn Seq=127668

9455 Len=0 Win=65535 Options=

cisprd01 -> xyz.corp.net TCP D=2164 S=1741 Rst Ack=127668

9456 Win=0

xyz.corp.net -> cisprd01 TCP D=1741 S=2164 Syn Seq=127668

9455 Len=0 Win=65535 Options=

cisprd01 -> xyz.corp.net TCP D=2164 S=1741 Rst Ack=127668

9456 Win=0

xyz.corp.net -> cisprd01 TCP D=1741 S=2164 Syn Seq=127668

9455 Len=0 Win=65535 Options=

cisprd01 -> xyz.corp.net TCP D=2164 S=1741 Rst Ack=127668

9456 Win=0

Joe Clarke Mon, 04/07/2008 - 18:41

It appears Apache is not running since the TCP SYNs to port 1741 are being RST'd. The casuser account looks fine, and this most likely has nothing to do with any missing environment variables. Again, I have to strongly caution you against this configuration as it was never tested.

rgomes Tue, 04/08/2008 - 05:36


I understand your advice but right now I am locked, out of the office and with a mission. Must work hard to try to run on this server before give up. If not suceed will have to negociate with customer. I have sent him the requirements and unfortunatly its not clear on them that Solaris Domains are not supported. For Windows till v3.0 was very clear on the FAQs, not on the requirements.

Back to my last post: the casuser that runs the procceses dont need to have /opt/CSCOpx/bin on his path?

Looking the output of netstat -na I see no Bind of the tcp 1741 port.

Can you give hints to debug the Apache activation?

Attached is the ps -ef listing showing all processes on the server.


Joe Clarke Tue, 04/08/2008 - 09:32

The PATH is set when dmgtd starts up. When processes spawn from dmgtd (some as casuser some as root) they inherit that PATH. You should not be trying to modify the casuser account in any way.

Logs relevant to Apache will be the daemons.log as well as /opt/CSCOpx/MDC/Apache/logs/error_log. Since Apache depends on the Tomcat process, you should check the output of pdshow to make sure Tomcat is running. If not, check the /opt/CSCOpx/MDC/tomcat/logs/stdout.log for errors.

rgomes Tue, 04/08/2008 - 10:20


Thanks once more. Let me point you my last actions:

1 - The Apache error_log was empty. I located the web_server script and started Apache by hand.

2 - The Apache proccess started and spawned several other children Apache proccesses, but named web_server on the ps listing because I startted by hand.

3 - I could connect to the server, but as soon I logged as admin, it changed the access from http to https and I got "Could not display ..." message for the https page. 4 - After this error I could not see the first page login any more. I tried kill and restart the Apache by hand but the first login page never showed up again.

5 - Then I looked the Apache error_log and there was some "unregistered errors".

6 - As the lms installation was made over one interrupted previous installation because of the former Mutex errors, I decided to clean the server. I run the uninstall.sh script rebooted the server and Im doing a new typical installation. As soon as it finishes I will update you.

7 - What proccess name in pdshow should be used for the Apache proccess?


rgomes Tue, 04/08/2008 - 13:17


Good News!

The clean installation after the uninstall worked OK sofar I could experiment it.

Now I am installing the Dec 2007 Update over it.

Hope it goes well like the other.

I will let you know.

So far two lessons learned:

1 - On error, do not interrupt the installation. Let it go and remove entirely afterwards.

2 - Localization must be en_US.ISO8859-1.


This Discussion