The port is being started by the manager. The error is happening during the
restart of the management server
2014-10-16 17:27:36,909 ERROR [c.c.c.ClusterManagerImpl] (main:null) Unable
to ping management server at 172.16.8.7:9090 due to ConnectException
java.net.ConnectException: Connection refused
at sun.nio.ch.Net.connect(Native Method)
at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:525)
at
com.cloud.cluster.ClusterManagerImpl.pingManagementNode(ClusterManagerImpl.java:1122)
at
com.cloud.cluster.ClusterManagerImpl.pingManagementNode(ClusterManagerImpl.java:1091)
at
com.cloud.cluster.ClusterManagerImpl.checkConflicts(ClusterManagerImpl.java:1169)
at
com.cloud.cluster.ClusterManagerImpl.configure(ClusterManagerImpl.java:1058)
.....
However, connecting afterwards with telnet is fine:
telnet 172.16.8.7 9090
Trying 172.16.8.7...
Connected to 172.16.8.7.
Escape character is '^]'.
^]
root@zee:/var/log/cloudstack/management# ps -ef |grep 32427
Non-standard uts for running kernel:
release Linux version 3.14-0.bpo.1-amd64 (debian-ker...@lists.debian.org)
(gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.14.4-1~bpo70+1
(2014-05-14)
=3.14.0 gives version code 200192
root 4553 4514 0 17:26 pts/6 00:00:00 grep 32427
cloud 32427 32424 1 15:26 ? 00:01:43 jsvc.exec -user cloud -cp
/usr/share/java/commons-daemon.jar:/usr/share/cloudstack-management/bin/bootstrap.jar:/etc/cloudstack/management:/usr/share/cloudstack-management/setup
-outfile SYSLOG -errfile SYSLOG -pidfile /var/run/cloudstack-management.pid
-Djava.awt.headless=true -Dcom.sun.management.jmxremote=false -Xmx2g
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/var/log/cloudstack/management/ -XX:PermSize=512M
-XX:MaxPermSize=800m
-Djava.endorsed.dirs=/usr/share/cloudstack-management/endorsed
-Dcatalina.base=/usr/share/cloudstack-management
-Dcatalina.home=/usr/share/cloudstack-management
-Djava.io.tmpdir=/tmp/cloudstack-management-temp
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
-Djava.util.logging.config.file=/usr/share/cloudstack-management/conf/logging.properties
org.apache.catalina.startup.Bootstrap
root@zee:/var/log/cloudstack/management# /etc/init.d/cloudstack-management
restart
[ ok ] Stopping CloudStack-specific Tomcat servlet engine:
cloudstack-management.
[ ok ] Starting CloudStack-specific Tomcat servlet engine:
cloudstack-management.
root@zee:/var/log/cloudstack/management# netstat -tulpn |grep 9090
root@zee:/var/log/cloudstack/management# netstat -tulpn |grep 9090
root@zee:/var/log/cloudstack/management# netstat -tulpn |grep 9090
root@zee:/var/log/cloudstack/management# netstat -tulpn |grep 9090
root@zee:/var/log/cloudstack/management# netstat -tulpn |grep 9090
tcp6 0 0 :::9090 :::*
LISTEN 4643/jsvc.exec
root@zee:/var/log/cloudstack/management# ps -ef |grep 4643
Non-standard uts for running kernel:
release Linux version 3.14-0.bpo.1-amd64 (debian-ker...@lists.debian.org)
(gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.14.4-1~bpo70+1
(2014-05-14)
=3.14.0 gives version code 200192
cloud 4643 4640 99 17:27 ? 00:00:52 jsvc.exec -user cloud -cp
/usr/share/java/commons-daemon.jar:/usr/share/cloudstack-management/bin/bootstrap.jar:/etc/cloudstack/management:/usr/share/cloudstack-management/setup
-outfile SYSLOG -errfile SYSLOG -pidfile /var/run/cloudstack-management.pid
-Djava.awt.headless=true -Dcom.sun.management.jmxremote=false -Xmx2g
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/var/log/cloudstack/management/ -XX:PermSize=512M
-XX:MaxPermSize=800m
-Djava.endorsed.dirs=/usr/share/cloudstack-management/endorsed
-Dcatalina.base=/usr/share/cloudstack-management
-Dcatalina.home=/usr/share/cloudstack-management
-Djava.io.tmpdir=/tmp/cloudstack-management-temp
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
-Djava.util.logging.config.file=/usr/share/cloudstack-management/conf/logging.properties
org.apache.catalina.startup.Bootstrap
root 4999 4514 0 17:27 pts/6 00:00:00 grep 4643
On 16 October 2014 17:16, Marc Leeman <marc.lee...@gmail.com> wrote:
>
> No:
>
> I killed the process at the boot the day before yesterday (thanks to the
> cloudstack guys that I made to miss the boot crawl): there was indeed a
> problem with that; NO vsm were starting.
>
> After killing the old stuck programs; we got further and after downloading
> the svm images manually with the http_proxy var; the svms started.
>
> However then we hit the bridging problem.
>
>
>
>
