reboot
-
-
Replying to @dark_kirb @FiloSottile
You continue to press Enter. After a few seconds, new lines stop to appear. You press "~.", your local shell prompt appears. You ping the server. After a few minutes, still no response. No luck with SSH either. You call Support. They tell you Game Over and offer Restart or Quit.
1 reply 4 retweets 12 likes -
In an alternate timeline, you get "Connection to server closed." You ping the server, it responds. After a few minutes, it still responds. No luck SSH'ing back in. You call Support. They restore your game for you, and reprimand you for your rookie move. It's your turn again.
2 replies 3 retweets 5 likes -
You take note of running services & containers, and of listening IPs:ports, so that you can verify exactly the same ones are back up after reboot. You sanity-check and save system time to NVRAM (affects fsck on bootup!) You check dmesg, and status of filesystems and RAID arrays.
1 reply 0 retweets 2 likes -
If switching to a different kernel, you prepare a "safety net": bootloader's automatic fallback to the current kernel on a 2nd reboot, "panic=60" to trigger that reboot on new Linux kernel's panic, and "/sbin/shutdown -r 5 &" in rc.local in case new kernel's networking fails.
1 reply 0 retweets 5 likes -
You possibly configure netconsole to a nearby server, or over the Internet if you specify the router's MAC address along with your logging machine's IP address. You manually shutdown services, but not sshd yet. You manually remount filesystems read-only. You think twice.
1 reply 0 retweets 2 likes -
If everything's OK, you "sync" and "reboot -f" (also syncs). If there are disk issues (sync might get stuck), you "reboot -nf" or (safer in terms of not trying to sync to possibly-stuck drives?) you "echo -en '\xfe' | dd of=/dev/port seek=100 bs=1 count=1" (surely everyone does).
1 reply 0 retweets 2 likes -
Once back in, you "shutdown -c" and remove it from rc.local. You sanity-check the system: what kernel booted up, as well as the checks similar to those you made pre-reboot (including verifying the same services are back up, etc. - perhaps using "diff -u" against your saved game).
1 reply 0 retweets 2 likes -
If you had enabled netconsole temporarily, you disable it. You make the new kernel the default. You stay around for a few hours doing other work yet checking your e-mail in case issues come up or are reported to you (and you had planned for this before starting to play the game).
1 reply 0 retweets 2 likes -
Alternately: if you had to spend this much time rebooting a single node, you already lost the game
1 reply 0 retweets 1 like
That's a valid alternative, yes. Depends on which game it was supposed to be and ended up being, which in turn depends on scale and more.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.