virsh shutdown <vm>: does not work (KVM) - virtual-machine

I've tried looking for a solution to shutdown vm from host in KVM and haven't found any. All I see is virsh shutdown <vm_name>, which does not work.
virsh destroy <vm_name> works, but that does not stop the VM gracefully. Does anyone know how to do this? (CentOS6)

Related

redis start with /usr/bin/redis-server fine but stop on systemd start

I have install redis on centos 8 and everything works fine but after I have reboot the server, redis top working, I have try to start by systemctl start redis but service start and stop unexpectedly
I have try /usr/bin/redis-server /etc/redis.conf and service start successfully but still got following error on starting bye systemctl
redis.service: Failed with result 'exit-code'
can anybody help me about this?
-----edit-------
I have check /var/logs/redis/redis.log and found that se linux cause the problme
I have try setenforce permissive and now redis working fine.
but why this happend?
I didn`t change anything about SELinux and suddenly the error occurred

redis - kill redis-server in google cloud platform

I am playing around Google Cloud Platform and Redis. But is is way more complicated than I expect.
I want to shutdown redis-server, in my local version i can just:
redis-cli shutdown
redis-cli ping // Could not connect to Redis at 127.0.0.1:6379: Connection refused
that means the redis-server no longer running.
But I cannot do that in GCP. I still can get PONG after the refis-cli shutdown.
I googled around and somebody suggest kill.
first find out what is the PID of the redis-server
ps -f -u redis
I will get:
which 1637 is the PID. so I do:
sudo kill 1637
and try refis-cli ping again, I still get PONG.
I tried ps -f -u redis again. I get:
It seems like for every kill, it will respawn it self with other PID.
How can I resolve this?
The redis-cli shutdown works on Mac OS. If you using Debian or Ubuntu, the easiest, way you can shutdown the server is to go into the server and type sudo service redis-server stop and service redis-server start to start it again.
Example
test-user#my-server:~$ sudo service redis-server stop
test-user#my-server:~$ ps -f -u redis
UID PID PPID C STIME TTY TIME CMD
test-user#my-server:~$
The question was answered in this community post. You may also see the following community tutorial on "How to Set Up Redis on Google Compute Engine"

vagrant up: config.ssh.timeout

I do not understand why I cannot "vagrant up" anymore after I run some provisioning scripts (I use ansible).
[default] Waiting for machine to boot. This may take a few minutes...
Timed out while waiting for the machine to boot. This means that
Vagrant was unable to communicate with the guest machine within
the configured ("config.ssh.timeout" value) time period. This can
mean a number of things.
If you're using a custom box, make sure that networking is properly
working and you're able to connect to the machine. It is a common
problem that networking isn't setup properly in these boxes.
Verify that authentication configurations are also setup properly,
as well.
If the box appears to be booting properly, you may want to increase
the timeout ("config.ssh.timeout") value.
What can be broken? What is vagrant trying to do when running vagrant up?
Connecting with the default user, i.e. "vagrant" ?
Obviously it is related to SSH.
Yes I pushed some SSH keys but I do not think I changed the vagrant user at all so "vagrant up" should still work right? I also changed a little bit the /etc/sudoers file but I tried without modifying it and it does not seem to work anyway...
Well, I am running out of ideas..
Thanks.
My 2 cents
Set vbox.gui to true in your Vagrantfile, this will help you to see if the box is booted correctly. It cloud get stuck during the boot process, however, vagrant is expecting an exit code from it, it timed out and you get what you saw.
After seeing the error message, run vagrant ssh and see what you get.
NOTE: you may need to enable debug to see more info: VAGRANT_LOG=debug vagrant up
BTW: make sure your vagrant (1.3.5) + VirtualBox (4.3.2) stays current.
Actually, this might not be an SSH issue. It sounds like your VM is hanging when you vagrant up and it may be the result of networking issues that can be cleared by restarting the networking when on your VM. Try the steps below to fix.
First, edit your Vagrantfile and add vb.gui = true to bring up your VM in a GUI mode. For example, my test Vagrantfile looks like:
VAGRANTFILE_API_VERSION = "2"
Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
config.vm.box = "testbox"
config.vm.network :private_network, ip: "192.168.50.102"
config.vm.provider :virtualbox do |vb|
vb.gui = true
end
end
Second, issue a vagrant up and your VM GUI will appear. Your vagrant will still hang but you should be able to log into your VM box via the GUI.
Third, open a terminal window and issue the following command:
sudo /etc/init.d/network restart
This should resolve your issue. You could issue a vagrant reload to refresh the VM.
Here's a reference to the vagrant hanging issue: https://github.com/mitchellh/vagrant/wiki/%60vagrant-up%60-hangs-at-%22Waiting-for-VM-to-boot.-This-can-take-a-few-minutes%22
(Note, my VM was a CentOS / VirtualBox instance.)
Starting a 64-bit vagrant box in a host not supporting virtualization leads to this error, you will see it if you start the VM in GUI mode.
I am using bento/ubuntu-16.04 and following steps solved my problem.
You need to change the following in
i. Go to this directory: cd ~/.vagrant.d/boxes/bento-VAGRANTSLASH-ubuntu-16.04/2.3.1/virtualbox
ii. Open box.ovf file using nano box.ovf
iii). Change <Adapter slot="0" enabled="true" MACAddress="080027C30A85" type="82540EM">
To
<Adapter slot="0" enabled="true" MACAddress="080027C30A85" cable="true" type="82540EM">
You might need to reboot your machine. To reboot follow these steps.
i. vagrant halt
ii. vagrant up
iii. vagrant ssh

Stop redis server. Neither shutdown nor stop works

I want to stop the redis server and it just keeps going and going. I am using redis-2.6.7
Check that it is running:
redis-server
It says "...bind: Address already in use" so it is already running.
I have tried
redis-cli
redis 127.0.0.1:6379> shutdown
It just hangs and nothing happens. I break out and check, yes, it is still running.
I have tried
redis-server stop
I get "can't open config file 'stop'"
I tried:
killall redis-server
Still running.
The reason that I want to stop it is that it is just hanging when I try to set or get a value via Python. So I thought that I would restart it.
EDIT:
No commands seem to work from redis-cli. I also tried INFO and it just hangs.
I finally got it down.
Get the PID of the process (this worked in Webfaction):
ps -u my_account -o pid,rss,command | grep redis
Then
> kill -9 the_pid
I was able to REPRODUCE this issue:
Start redis-server
Then break it using Pause/Break key
Now it hangs and it won't shutdown normally. Also the Python program trying to set/get a key hangs. To avoid this: Just close the window after starting redis-server. It's now running normally.
I can't reproduce the problem anymore, but shutdown NOSAVE helped me, when I was playing with redis and couldn't get it to shut down:
redis-cli
127.0.0.1:6379> shutdown
(error) ERR Errors trying to SHUTDOWN. Check logs.
127.0.0.1:6379> shutdown NOSAVE
not connected>
Shutdown Redis Server $ redis-cli -a password -p 6379 shutdown
Start Redis Server $ sudo service redis_6379 start
It works on Ubuntu Server 14.04 x86 Redis v2.8.15.
Depending on your setup, either of the following solutions might fail, with redis-server just restarting with a new PID:
1.
redis-cli -a password shutdown
or, 2.
ps aux|grep redis
kill -9 <redis pid>
But the below command works.
/etc/init.d/redis-server stop
My server is Ubuntu 18.04.2 and Redis version is v4.0.9
The normal way of doing this is to connect to a client like redis-cli and execute "shutdown" command. I've found some issues trying to shutdown because redis-server doesn't have right permissions to edit db dump file (RDB) prior to quit. Then redis remains started and you have to kill the process with kill -9 pid. But this is not a redis problem as you may know.
Example of this problem:
# User requested shutdown...
[16560] 10 Sep 11:21:17.672 * Saving the final RDB snapshot before exiting.
[16560] 10 Sep 11:21:17.672 # Failed opening .rdb for saving: Permission denied
[16560] 10 Sep 11:21:17.672 # Error trying to save the DB, can't exit.
If You use Ubuntu or other linux distros try stop redis server:
sudo service redis-server stop
i think shutdown command can shutdown the redis server.
Maybe strange,after typed shutdown command,the redis-cli does not exit.Meanwhile ,the server has shutdowned.
This is possibly an really important note for some people reading this. If your redis doesn't seem to be responding to a shutdown. CHECK THE LOGS.
They may say something like this:
Apr 24 00:48:54 redis[828]: Received SIGTERM, scheduling shutdown...
Apr 24 00:48:54 redis[828]: User requested shutdown, saving DB...
Apr 24 00:55:37 redis[828]: DB saved on disk
Maybe your DB is multiple GB, or tens of GBs in which case it will take time to shutdown. If instead you want to clean out all keys, there is a better way to do that than shutdown. FLUSHALL
On windows this worked:
Open terminal(PowerShell/CMD), type:
wsl --shutdown
It will end your virtual machine.
net stop redis
should do the trick
to start :
net start redis
see this https://stackoverflow.com/a/20153062
When setting up the server to require auth...
The redis start and shutdown script utilizes redis-cli, which means that shutdown will not happen without auth and the server will hang in a loop waiting for redis to shutdown, which won't ever happen without auth.
So in the shutdown script you have to change
$CLIEXEC -p $REDISPORT shutdown
to
$CLIEXEC -a 'authpassword' -p $REDISPORT shutdown
in order to allow your redis service to shutdown without hassle.
Best way check pid of redis opened port :
lsof -i:<redis-port>
for default redis port
lsof -i:6379
kill -9 <pid>
I had a Could not connect to Redis at 127.0.0.1:6379: Connection refused error and nothing worked for me from the suggested solutions.
My solution: run sudo redis-server /etc/redis.conf command in the terminal.
After running the command I was able to use Redis again without that error.
Note: I do not know if it is OS-dependent, but I use Manjaro Linux. I am not sure if it will work the same on a different OS.
You use the following command to kill the running redis-server process.
ps aux |grep redis
This will list all the running processes for redis-server.
Then you can use the following command to kill the redis processes
sudo kill <pid for redis>
sudo kill 7229 //for the above sample.
start redis: $REDIS_HOME/src/redis-server
stop redis: $REDIS_HOME/src/redis-cli shutdown
$REDIS_HOME where you have installed/extracted redis.
on redis-cli command "shutdown SAVE" or "shutdown NOSAVE" will work.

fabric appears to start apache2 but doesn't

I'm using fabric to remotely start a micro aws server, install git and a git repository, adjust apache config and then restart the server.
If at any point, from the fabfile I issue either
sudo('service apache2 restart') or run('sudo service apache2 restart') or a stop and then a start, the command apparently runs, I get the response indicating apache has started, for example
[ec2-184-73-1-113.compute-1.amazonaws.com] sudo: service apache2 start
[ec2-184-73-1-113.compute-1.amazonaws.com] out: * Starting web server apache2
[ec2-184-73-1-113.compute-1.amazonaws.com] out: ...done.
[ec2-184-73-1-113.compute-1.amazonaws.com] out:
However, if I try to connect, the connection is refused and if I ssh into the server and run
sudo service apache2 status it says that "Apache is NOT running"
Whilst sshed in, if run
sudo service apache start, the server is started and I can connect. Has anyone else experienced this? Or does anyone have any tips as to where I could look, in log files etc to work out what has happened. There is nothing in apache2/error.log, syslog or auth.log.
It's not that big a deal, I can work round it. I just don't like such silent failures.
Which version of fabric are you running?
Have you tried to change the pty argument (try to change shell too, but it should not influence things)?
http://docs.fabfile.org/en/1.0.1/api/core/operations.html#fabric.operations.run
You can set the pty argument like this:
sudo('service apache2 restart', pty=False)
Try this:
sudo('service apache2 restart',pty=False)
This worked for me after running into the same problem. I'm not sure why this happens.
This is an instance of this issue and there is an entry in the FAQ that has the pty answer. Unfortunately on CentOS 6 doesn't support pty-less sudo commands and I didn't like the nohup solution since it killed output.
The final entry in the issue mentions using sudo('set -m; service servicename start'). This turns on Job Control and therefore background processes are put in their own process group. As a result they are not terminated when the command ends.
When connecting to your remotes on behalf of a user granted enough privileges (such as root), you can manage system services as shown below:
from fabtools import service
service.restart('apache2')
https://fabtools.readthedocs.org/en/0.13.0/api/service.html
P.S. Its requires the installation of fabtools
pip install fabtools
Couple of more ways to fix the problem.
You could run the fab target with --no-pty option
fab --no-pty <task>
Inside fabfile, set the global environment variable always_use_pty to False, before your target code executes
env.always_use_pty = False
using pty=False still didn't solve it for me. The solution that ended up working for me is doing a double-nohup, like so:
run.sh
#! /usr/bin/env bash
nohup java -jar myapp.jar 2>&1 &
fabfile.py
...
sudo("nohup ./run.sh &> nohup.out", user=env.user, warn_only=True)
...