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

Reply via email to