It happen to me to find a VM in XEN run out of memory, OS kill its shell tty so there is no way to input command in VM internally. The only way to fix is shutdown or reboot the VM.
"xm shutdown VM-name" and "xm reboot VM-name" have been tried, but not work. XEN is working fine, the rest VMs are all good, and xm command work for them too. only the ill VM out of control.
Is there any XEN command to shutdown or reboot its VM by force? e.g. some command with "--force" flag.
"xm reboot" and "xm shutdown" are too grace in my case, I think.
The XEN version I used is xen-3.0-x86_64 (debian).
The xmoption you probably want (although it should really be a last resort) is xm destroy.
xm destroy domain-id
Immediately terminate the domain domain-id. This doesn't give the domain OS any chance to react, and it the equivalent of ripping the power cord out on a physical machine. In most cases you will want to use the shutdown command instead.
I had issue with "xm reboot", it will not effect and cause subsequence "xm shutdown" has no effect too. So I think the best approach is to "xm shutdown", check "xm uptime" the domain to see if it shutdown, or until timeout and call "xm destroy"
Related
I have Redhat 6.10 Synchronizer Server and xen client device setup. I am able to download updates via a manager software which run on xen client device.
But each time I want to download the update.tar
I restart the apache and then client xen device.
or I have to reboot the xen client device which I want to update then it downloads.
But sometimes even on xen client device reboot the update.tar wont download.
xen-client: downloading ....and it just keeps downloading without downloading it. It times out. I believe that for the update to download on the xen client device just restarting the xen client or invoking the client service should be enough. There should be no need to restart apache and then restart the xen-vm-client.
I am not able to download without restarting the httpd server. ie I have to run 'service httpd restart' and then immediately 'xen-vm-client reboot' . But without this I am not able to download the update.tar by just firing 'xen-vm-client reboot' on Xen. I have to restart httpd and then xen client device for it to download.
I had an issue with Redhat 6.10. After 'yum install httpd' and rebooting redhat it wont boot up. And then after debugging through the boot process, I figure out that httpd service running at different runlevels on boot stops redhat from booting up. So had to
chkconfig httpd off
chkconfig httpd --del
This fixed the issue of httpd at runlevels hanging the redhat bootup. But I think this could be the reason why I have to restart httpd to get the update to download. Otherwise if I reboot the xen client device it downloads without a httpd restart. So any hints/ideas are really appreciated.
Please give me some understanding about why this is happening and how this can be solved if you know.
Once again grateful for all the help.
Regards
Shraddha
Next what I ll try is 'chkconfig httpd on' this might again cause the redhat to hangup on booting. And thus I may have to reinstall the entire Synchronizer redhat 6.10 setup. Or still trying to investigate about the issue.
I'm newly moving from a Linux working environment to Windows, and I'm mainly using local port forwarding+Pycharm to run my python code on a server that is double-hop from my laptop.
I am able to establish the ssh tunnel through Windows cmd or MobaXterm local terminal or MobaXterm tunneling tool. I works fine on my Pycharm, when I check it from tools/deployment/configuration/test connection, and I can also see the files in remote server. But every time I start my Pycharm, it shows two background process, "updating python interpreter" and "updating pycharm helper", and the precess bar simply do not show any moving on! And I cannot run python on remote server, because Pycharm says I lack python helper.
And most wired, when it is running these two precess, my terminal for local port forwarding freezes, and I cannot type in commands in the jump server. And when I try to recheck the connection, it turns out that connection fails.
My ssh tunneling+pycharm deployment used to work fine in my Ubuntu. Thanks anybody who can shed light on my confusion!
Well, thanks everyone, I have solved this problem.
The reason is simple, but I did not notice that the ~/.pycharm_helper 's size is actually changing in the process, while the GUI bar may be not moving.
So it is due to my double-hop inconvenience, and the low Internet speed. I left it in dorm for a whole night out, and it comes out just fine.
This has happened to me on multiple occasions and I can't seem to pinpoint the cause of it.
Whenever I try to shutdown or reboot the Raspberry Pi via an SSH connection, the system broadcasts it's halting, but doesn't close the SSH connection. Instead it's left hanging until I type something after a minute and it notes a "Broken Pipe" error.
The weird thing about this is that it's random across installs.
On my Pi B, Rev 1, the connection closes. Initially this was the case on my Pi 3, but after a reinstall of Raspbian it stopped closing it. Another reinstall fixed it, but yesterday I reinstalled again and the problem came back.
It's seems that I'm the only one who has this problem (or at least has queried other about in online) so I thought I'd pick the brains of whoever stumbled upon this question. Anyone have any idea why this happens?
P.S. it's doesn't happen to my other servers, only to the Pi's.
This probably happens as a result of the order of the steps performed during system shutdown.
The recommended solution is installing libpam-systemd and dbus and making sure that UsePAM is enabled in sshd_config:
apt-get install libpam-systemd dbus
See the following links for a more detailed explanation:
https://serverfault.com/questions/706475/ssh-sessions-hang-on-shutdown-reboot
https://unix.stackexchange.com/questions/216950/after-sending-shutdown-command-ssh-session-doesnt-terminate
I need to understand a fundamental concept about terminal multiplexers yet I can't seem to find the answer.
As I understand these programs need to be installed on server but not necessarily on clients. It's not a problem with gnu-screen as it is already installed on most systems but it's not the case for tmux and byobu. The problem is that I don't have permission to install software on the server. Is there a way I can run byobu from my client to show statistics about the server I connect?
Also what exactly is the effect of 'byobu-enable' option?
I think there is a misunderstanding here. When you connect to the server and run a command (byobu in this case), you are running the command on the server. Statistics reported are for the server. It's possible to open a byobu session on your own desktop of course, but if you're ssh'd into a machine, you're very likely to be executing commands on that machine.
byobu-enable sets byobu to launch automatically when you open a terminal. I don't do this since you can have confusion if you have byobu running locally and on the remote end you have connected to, which causes problems when you try to interact with byobu itself.
I'm working on a hardware driver installer/updater. Part of the installer/updater installs an updated FPGA firmware. A requirement of the card when upgrading the FPGA firmware is that the machine must be fully powered down for the firmware upgrade to take effect. I have found the schedule and force reboot properties for MSI installers, but haven't found an analogue to force or schedule a shutdown. Is there anything in msi/windows-installer/WiX to do this, or can anyone suggest a way of accomplishing this?
You could use the QuietExecute CA to call shutdown or write your own CA. Also be sure to set the /f for force option. Otherwise, be really careful that you give users the ability to supress this shutdown. Another thought might be to have your application tell the user that the software won't work until the hardware has been cold started instead of having the installer do it.
You could try running "Shutdown -s" to shut the machine down. Take a look at http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/shutdown.mspx?mfr=true