Is the log you posted a piece of catalina.out or the management-server.log?
Normally when the container (in this case Tomcat) does not go up, I try to check the container log files, which may contain log entries that are not logged in the application log file. For tomcat, I normally check the catalina.out. On Fri, Feb 3, 2017 at 9:40 AM, Will Stevens <williamstev...@gmail.com> wrote: > Hey All, > I have been doing the same upgrade path for months. It basically goes like > this. I am running CentOS6.8. > > - Build code with jenkins and publish to a repo > - Backup /etc/cloudstack/management/db.properties -> db.properties.bck > - Update my /etc/yum.repos.d/cloudstack.repo file to point to the new > build > - Since it is the same version as the last time (4.10), I have to remove > the old packages > -- sudo yum -y remove cloudstack-management cloudstack-common > cloudstack-usage > - Install the new packages > -- sudo yum -y install cloudstack-management cloudstack-usage > - Copy the db.properties.bck to db.properties > - Restart the service > > I recently pulled in the latest code from master and now I get different > behavior. > > When I install the packages, I get this: > --- snip --- > Running Transaction > Installing : cloudstack-common-4.10.0.0-SNAPSHOT.el6.x86_64 1/3 > Installing : cloudstack-management-4.10.0.0-SNAPSHOT.el6.x86_64 2/3 > Unable to determine ssl settings for server.xml, please run > cloudstack-setup-management manually > Unable to determine ssl settings for tomcat.conf, please run > cloudstack-setup-management manually > Installing : cloudstack-usage-4.10.0.0-SNAPSHOT.el6.x86_64 3/3 > Replacing db.properties with management server db.properties > Replacing key with management server key > Verifying : cloudstack-common-4.10.0.0-SNAPSHOT.el6.x86_64 1/3 > Verifying : cloudstack-usage-4.10.0.0-SNAPSHOT.el6.x86_64 2/3 > Verifying : cloudstack-management-4.10.0.0-SNAPSHOT.el6.x86_64 3/3 > > Installed: > cloudstack-management.x86_64 0:4.10.0.0-SNAPSHOT.el6 > cloudstack-usage.x86_64 0:4.10.0.0-SNAPSHOT.el6 > > > Dependency Installed: > cloudstack-common.x86_64 0:4.10.0.0-SNAPSHOT.el6 > > Complete! > --- snip -- > > I check what files are in the '/etc/cloudstack/management' folder. > > --- snip relevant --- > server-nonssl.xml > server-ssl.xml > server.xml -> /etc/cloudstack/management/server-nonssl.xml > tomcat6.conf -> /etc/cloudstack/management/tomcat6-nonssl.conf > tomcat6-nonssl.conf > tomcat6-ssl.conf > tomcat-users.xml > --- snip relevant --- > > I notice that 'server.xml' is there, but 'tomcat.conf' is not. > > I run 'cloudstack-setup-management' as it says in the instructions. > > --- > $ sudo cloudstack-setup-management > Starting to configure CloudStack Management Server: > Configure Firewall ... [OK] > Configure CloudStack Management Server ...[OK] > CloudStack Management Server setup is Done! > --- > > It does not seem to have changed anything in '/etc/cloudstack/management' > folder. > > I try to start the CloudStack Management service and then tail the log and > I get this in the logs and the service does not start. > > --- snip --- > 2017-01-18 20:01:19,134 INFO [o.a.c.s.l.CloudStackExtendedLifeCycle] > (Thread-90:null) (logid:) stopping bean ClusterServiceServletAdapter > 2017-01-18 20:01:19,135 ERROR [c.c.c.ClusterServiceServletContainer] > (Thread-10:null) (logid:) Unexpected exception > java.net.SocketException: Socket closed > at java.net.PlainSocketImpl.socketAccept(Native Method) > at java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java: > 398) > at java.net.ServerSocket.implAccept(ServerSocket.java:530) > at java.net.ServerSocket.accept(ServerSocket.java:498) > at > com.cloud.cluster.ClusterServiceServletContainer$ListenerThread.run( > ClusterServiceServletContainer.java:131) > 2017-01-18 20:01:19,135 INFO [o.a.c.s.l.CloudStackExtendedLifeCycle] > (Thread-90:null) (logid:) stopping bean ClusterManagerImpl > 2017-01-18 20:01:19,135 INFO [c.c.c.ClusterManagerImpl] (Thread-90:null) > (logid:) Stopping Cluster manager, msid : 7617392934992 > --- snip --- > > I am not sure what changed on master that would have caused this, but > apparently something is unhappy. > > Any ideas for how to resolve this and make sure upgrades still work for > ACS? > > Thanks, > > Will > -- Rafael Weingärtner
