cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1636
Views
0
Helpful
4
Replies

Problems with Tomcat and apache

pcuervo123
Level 1
Level 1

I have done a clonning of my active disk in Solaris 9. When I reboot with the cloned disk, some of the processes refuse to start.

Process= Tomcat

State = Administrator has shut down this server

Process= Apache

State = Never started

Process= TomcatMonitor

State = Never started

Process= DCRServer

State = Never started

Process= CMFOGSServer

State = Never started

Process= CampusOGSServer

State = Never started

I guess it has something to do with Tomcat. I have tried to stop and start the LMS daemon, unsuccessfully. If I reboot using the original disk, no problem at all. How is this possible? The second disk is a physical copy of the first.

Thanks.

1 Accepted Solution

Accepted Solutions

The problem may very well be the permissions of the underlying mount points. Unmount the file system in which CiscoWorks is installed (e.g. /opt), and look at the permissions on the /opt directory:

# ls -ld /opt

They should be 0755. If not, change them, then remount /opt, and try dmgtd again. You may need to repeat this with your other file systems.

View solution in original post

4 Replies 4

Joe Clarke
Cisco Employee
Cisco Employee

Were all file systems cloned? CiscoWorks requires data in /, /var, and /opt for proper operation.

You may find additional information about why Tomcat is not starting in /opt/CSCOpx/MDC/tomcat/logs/stdout.log.

The clonning is a low level copy of the whole disk using the Solaris9 tool 'lu' so all the bits in both disk are supposed to be exactly the same. Find below the output of the log.

#cat stdout.log

Error occurred during initialization of VM

java.lang.Error: Properties init: Could not determine current working directory.

Since I installed it on the disk 0, I guess there's some parameter related to disk 0 and now when it tries to start from the disk 1 some initial configuration is wrong since it corresponds to disk 0 and not 1. Maybe the disk name is part of the working directory? Some idea?.

The problem may very well be the permissions of the underlying mount points. Unmount the file system in which CiscoWorks is installed (e.g. /opt), and look at the permissions on the /opt directory:

# ls -ld /opt

They should be 0755. If not, change them, then remount /opt, and try dmgtd again. You may need to repeat this with your other file systems.

Thanks for your support, that fixed the problem. I don't understand why the 'lu' tool the changed permissions.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: