I have deployed an "helloworld" service on cloudify 2.7 and OpenStack cloud. I would stop the service tomcat without the service is being restarted.
So, in the cloudify shell I have execute:
cloudify#default> connect cloudify-manager-1_IP
Connected successfully
cloudify#default> use-application helloworld
Using application helloworld
cloudify#helloworld> invoke tomcat cloudify:start-maintenance-mode 60
Invocation results:
1: OK from instance #1#tomcat_IP, Result: agent failure detection disabled successfully for a period of 60 minutes
invocation completed successfully
At this point, I have connected via ssh into the tomcat VM and ran:
CATALINA_HOME/bin/catalina.sh stop
In the CATALINA_HOME/log/catalina.out I can see that the app server is being stopped and immediately restarted!
So, what should I do in order to stop the app server and restart it only when I decide to restart it?
Maintenance mode in Cloudify 2.7 is used to prevent the system from starting a new VM if a service VM has failed.
What you are looking for is to prevent Cloudify from auto-healing a process - Cloudify checks for the liveness of the configured process, and if it dies, it executes the 'start' lifecycle again.
In your case, the monitored process can change, since you will be restarting it manually. So you should not use the default process monitoring. There is a similar question here: cloudify 2.7 locator NO_PROCESS_LOCATORS
Related
I am seeking to set up a Release Pipeline in Azure DevOps Services that will deploy
an application to a Unix server, where it then executes some unix commands as part
of the deployment.
Would appreciate some guidance on which pipeline Task(s) I can set up to therefore
achieve the following objectives:
Connect to the Unix server.
Execute the required Unix commands.
By the way, the Agents are currently installed on Windows hosts but we are looking to
extend that to Unix servers in due course, so a solution that fits both setups would
be ideal, even though the former is the priority.
You can check out task SSH Deployment task.
Use this task to run shell commands or a script on a remote machine using SSH. This task enables you to connect to a remote machine using SSH and run commands or a script.
If you need to copy files to the remote linux server. You can check out Copy Files Over SSH task.
You probably need to create a SSH service connection. See steps here to create as service connection.
In the end, due to concerns raised about the install of private keys on the target server which is part of the SSH Deployment setup, we opted for the use of Deployment Groups which has enabled us to set up a persistent connection to our Linux server.
I have installed Zenoss 5.2.4 on a machine which runs centos 7. I wanted to reboot the machine and thus stopped the serviced for graceful shutdown of all the internal services for Zenoss.
Upon rebooting, I see the serviced is already running. This shows that the Zenoss.core is started upon system boot time. I want to start the serviced and Zenoss.core manually after the system reboots. How can I turn on this feature??
I checked in the /etc/default/serviced configuration file but couldn't get any such parameter.
Thanks.
I did a systemctl disable serviced before restart and it didn't started up anymore automatically. I enabled and started serviced manually.
I have created basic ASP.Net Core server on Azure Ubuntu VM. I have exposed the server to a port 80 using nginx.
I am conecting to the VM via ssh.
And starting the server with "dotnet run" command.
That works fine.
However, every time I close the ssh connection, the server is stopping as well.
Is there a way to start and keep running the asp.net core server on Linux without having an active ssh connection?
Basically what happens is:
You login with ssh
you startup an application under your user (dotnet run)
Close your ssh => logging out user, which means application is closed.
You need to start a service outside of your user. Here is some information:
https://askubuntu.com/questions/8653/how-to-keep-processes-running-after-ending-ssh-session
Otherwise i'd advice you to ask on https://askubuntu.com/
I am attempting to follow this tutorial: http://docs.kaaproject.org/display/KAA/Raspberry+Pi
When I run the final commands:
tar -zxf notification_demo.tar.gz
cd CppNotificationDemo/
./build.sh deploy
After it finishes building it displays:
Press Enter to subscribe to optional topics
I press Enter, then it displays:
Press Enter to exit
I do not press Enter, and after a couple minutes this error message shows up
[client_1][2017-Jan-19 11:29:22.287762][0x755ff450][warning][HttpClient.cpp:41]:Transport error occurred: Connection timed out
[client_1][2017-Jan-19 11:29:22.313916][0x755ff450][warning][AbstractHttpChannel.cpp:103]: Channel [default_bootstrap_channel] failed to connect 130.113.109.160:9889: Connection timed out
[client_1][2017-Jan-19 11:29:22.353513][0x755ff450][warning][AbstractHttpChannel.cpp:124]: Channel [default_bootstrap_channel] detected 'CURRENT_BOOTSTRAP_SERVER_NA' failover for TransportConnectionInfo{ server: 'BOOTSTRAP', protocol: 'TransportProtocolId{ id: 0xfb9a3cf0, version: 1 }', accessPointId: -1835393002, isFailed: 'false' }
[client_1][2017-Jan-19 11:29:22.354396][0x755ff450][warning][KaaChannelManager.cpp:157]: No Bootstrap services are accessible for TransportProtocolId{ id: 0xfb9a3cf0, version: 1 }. Processing failover...
[client_1][2017-Jan-19 11:29:22.355018][0x755ff450][warning][KaaChannelManager.cpp:148]: Attempt to reconnect to first Bootstrap service will be made in 5 seconds
What does this error message mean, and how do I solve this?
That message usually means the application cannot connect to the Kaa Sandbox. There might be several issues with that and you should try all of them until it start working.
Ensure you run the application from the same PC host the Kaa Sandbox is running. In this case, with the default Sandbox configuration the application should be able to normally access all the necessary Kaa services located on the Kaa Sandbox with no additional configuration.
If you need to run the application remotely (i.e. from another host PC and the Kaa Sandbox virtual machine is accessible through the local network), you need to change the Kaa host configuration on the Administration UI, Manage page to the real IP address of the PC host the Kaa Sandbox is running on. Then, you will need to re-generate Kaa SDK, download it and use during the application build.
If neither of this works for you, the network and (or) other configuration is incorrect and need investigation. Please describe your network topology, all the PC hosts involved, what steps did you go after downloading of the Kaa Sandbox and how did you build the application. We will analyse this data and try identify the issue root cause.
I use AWS CodeDeploy to deploy builds from GitHub to EC2 instances in AutoScaling Group.
It's working fine for Windows 2012 R2 with all Deployment configurations.
But for Windows 2016 it totally fails on "OneAtTime" deploy;
During "AllAtOnce" deploy only one or two instances deployed successfully, all other fails.
In the logfile on agent this suspicious message is present:
ERROR [codedeploy-agent(1104)]: CodeDeploy Instance Agent Service: CodeDeploy Instance Agent Service: error during start or run: Errno::ETIMEDOUT
- A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. - connect(2)
All policies, roles, software, builds and other stuff are the same, I even tested this on brand new AWS account.
Does anybody faced such behaviour?
I ran into the same problem, but during my investigation, I found out that server's route table had wrong routes for 169.254.169.254 network (there was specified the gateway from the network where my template was captured), so that it couldn't read instance metadata.
From the above error it looks like the agent isn't able to talk to CodeDeploy endpoint after instance starts up. Please check if the routing tables and other proxy related settings are set up correctly. Also if you do not have it already, you can turn on the debug log by setting :verbose to true in the agent config and restart the agent. This would help debug the issue better.