Team i need to know how gcp compute instances stop [instance name] command works internally.
Need to know it does graceful shutdown or non graceful shutdown?
Also need to know ,is there any way via cli we can do non graceful (VM)shutdown?
That command could be considered as a grateful shutdown if the VM responds appropiately. If in a given time frame it doesn't, it will be forced to shutdown. I don't think there is a way to do a non-grateful, forced shutdown without attempting a ACPI signal first.
Stopping a VM causes Compute Engine to send the ACPI shutdown signal to the VM. Modern guest operating systems (OS) are configured to perform a clean shutdown before powering off in response to the power off signal. Compute Engine waits a short time for the guest OS to finish shutting down and then transitions the VM to the TERMINATED state.
https://cloud.google.com/compute/docs/instances/stop-start-instance
https://cloud.google.com/sdk/gcloud/reference/compute/instances/stop
Related
Suppose I have 20 process/deqamons running in my linux system,
How different the HALT will have an effect on my process/deamons, when compared to a SHUTDOWN
Generally, one uses the shutdown command. It allows a time delay and warning message before shutdown or reboot, which is important for system administration of multiuser shell servers; it can provide the users with advance notice of the downtime.
As such, the shutdown command has to be used like this to halt/switch off the computer immediately (on Linux and FreeBSD at least):
shutdown -h now
Or to reboot it with a custom, 30 minute advance warning:
shutdown -r +30 "Planned software upgrades"
After the delay, shutdown tells init to change to runlevel 0 (halt) or 6 (reboot). (Note that omitting -h or -r will cause the system to go into single-user mode (runlevel 1), which kills most system processes but does not actually halt the system; it still allows the administrator to remain logged in as root.)
Once system processes have been killed and filesystems have been unmounted, the system halts/powers off or reboots automatically. This is done using the halt or reboot command, which syncs changes to disks and then performs the actual halt/power off or reboot.
On Linux, if halt or reboot is run when the system has not already started the shutdown process, it will invoke the shutdown command automatically rather than directly performing its intended action. However, on systems such as FreeBSD, these commands first log the action in wtmp and then will immediately perform the halt/reboot themselves, without first killing processes or unmounting filesystems.
On POSIX systems the shutdown command switches runlevels, and executes the appropriate scripts.
On FreeBSD the "halt" command is an ACPI thing...
If you have particular concerns or would like to know things the general documentation wouldn't readily address, please feel free to refine your query.
I am using linux watchdog driver /dev/watchdog on a linux embedded system with busy box as user space tools. I want to trigger the watchdog from C/C++ code, which works fine for timeouts up to 60s:
watchdogFD = open( "/dev/watchdog", O_WRONLY );
int timeout = 60;
ioctl( watchdogFD, WDIOC_SETTIMEOUT, &timeout )
However for larger intervals the timeout is accepted, but the watchdog is triggered already after 60s.
The linux watchdog deamon offers a --force parameter to set timeouts larger than 60s (see https://linux.die.net/man/8/watchdog). However the busy box watchdog deamon does not offer this (see https://git.busybox.net/busybox/tree/miscutils/watchdog.c?id=1572f520ccfe9e45d4cb9b18bb7b728eb2bbb571).
Does anyone have a suggestion how to use the same --force option when controlling watchdog using ioctl? Thanks :)
It seems the busybox watchdog daemon you link to is very simple compared to the usual Linux one from here:
https://sourceforge.net/p/watchdog/code/ci/master/tree/
The --force option for the Linux daemon (above) is to override the sanity checks on the polling interval versus the hardware time-out used. It will not change any limits a specific hardware driver/timer has to offer.
Typically the choice of hardware time-out is in the 10-60 second range, depending on how long you can tolerate a major fault (like a kernel panic) persisting for. Then the watchdog daemon that feeds the timer has to poll at an interval that is at least a few seconds shorter so nothing timers out unexpectedly. Between polls it uses nanosleep() so gives up its CPU time, and so the system load for the daemon is proportional to the polling rate and the type of tests that are run.
Without any tests all you protect against is a major fault killing either the daemon or kernel, so usually you should be checking for something else that is essential for normal operations (e.g. a specific process being alive, files being updated, test script can be run, etc) to get the most benefit.
Google Compute Engine rents all size Linux VMs from 1 core to 64 cores at various prices. There are "preempt-able" instances for about 1/4 the price of guaranteed instances, but the the preempt-able instances can be terminated at any time (with an ACPI G2 soft off warning and ~ 30 secs until hard cutoff). Although you can provide a startup and shutdown script, the usual approach seems to lead to the unnecessary overhead of having to then create additional software to allow calculations to be interrupted, and to manage partial results of calculations whereas the suspend-to-disk/restore-from-disk scheme seen in laptops and desktops could be a much simpler approach to storing and resuming calculations and therefore preferable.
If I start a Linux preemptible VM on GCE, is it possible generally to suspend the state of the VM to the disk (aka hibernate) and restart a new preemptible VM from the disk afterwards? My idea is:
Start a new preemptible Linux VM.
When the OS receives the the preemption notice (ACPI G2 Soft Off signal), then trigger suspend the to disk - hibernate the Linux OS.
Start a new preemptible Linux VM from the suspended image, i.e. restore the former VM and continue in the computation.
How would I configure Linux to suspend/restore in this way?
I am running an ubuntu precise host with some lxc containers in it.
Should or have i to shut down containers before shutting down the host ?
Or host shutdown is propagated to containers automatically ?
I know if i use lxc autostart feature, then that will shutdown containers, but i do not want to use autostart.
The containers themselves are usually running on the host system's filesystem, and don't have their own filesystem. This means that from filesystem point of view, you can just kill LXC without risking any filesystem corruptions.
But if you have services running inside LXC, like for example MySQL, or other services that require a clean shut down for their own data stores, then it's important that these processes get stopped cleanly. Otherwise you risk causing corruptions on the data store of these services.
If you use the script in /etc/init.d to start your LXCs, they should get the signal to shutdown automatically once you shut down your host system, because init will call the /etc/init.d/ stop. If you started them manually, like via lxc-start on the CLI, and you want to be sure that they get shut down cleanly, it's better if you do it manually before shutting down the host system.
hope that helps.
While shutting down QNX neutrino using phshutdown(either reboot or shutdown),system hangs while killing message queues(mqueue).the message displayed on screen is
Shutting down service providers(mqueue)
What could be the reason for this ?
This happens from time to time when you issue shutdown from the command line as well.
Some of the reasons I've seen on the web are:
Hardware issue
Driver issue
Kernel told to shut down when it didn't want to
From what I've cobbled together (and this is by no means definitive, but seems to be plausible), basically, any program that is waiting for the hardware or OS to reply has a chance of hanging the shutdown if the thing it is waiting on gets killed before it does.
A possible mitigation is to slay all your apps/servers (especially those touching hardware devices or shared memory queues) prior to issuing a shutdown, wait for a second or two, then go ahead with your shutdown.