(Update below)
Here’s an interesting Linux tidbit that not many ESX admins realize.
reboot is not the same as init 6
In Linux, the init 6 command gracefully reboots the system running all the K* shutdown scripts first, before rebooting. The reboot command does a very quick reboot. It doesn’t execute any kill scripts, but just unmounts filesystems and restarts the system. The reboot command is more forceful.
So, should I use reboot or init 6? – neither! My advice is to use the shutdown command. shutdown will do a similar job to init 6, but it has more options and a better default action. Along with kicking off an init 6, the shutdown command will also notify all logged in users (logged in at a tty), notify all processes the system is going down and by default will pause for a set time before rebooting (giving you the chance to cancel the reboot if you realize that you made a mistake). Jolly civil.
–
How does this advice apply to VMware ESX servers you ask? Well I’m not a VMware kernel developer so to be honest I’m not the best person to ask (if you do know murky details, then please let us know in the comments). However I will say this; I will always use shutdown -r first and foremost. It’s just a better habit to get into.
Is there a difference on an ESX server? Yes, but as I said I’m entirely sure how it affects the VMkernel processes. The reason I definitely know – a couple of times I’ve had to use the reboot command to force an unresponsive ESX shutdown -r.
P.S. This also applies to init 0 / halt (i.e. use shutdown -h instead).
***************
Update: Following Andrew’s comments below I’ve done a bit more digging. He’s correct that the default action of the reboot command has now changed to call the shutdown command. This upstream change (presumably because its a safer default action as I explained above) is now reflected in a lot of the current distributions, including the Service Console that comes with ESX 4.0. So if you want to force a reboot you have run reboot -f.
Here’s the section on ESX4 man page explaining the change:
NOTES
Under older sysvinit releases , reboot and halt should never be called directly. From release 2.74 on halt and reboot invoke shutdown(8) if the system is not in runlevel 0 or 6. This means that if halt or reboot cannot find out the current runlevel (for example, when /var/run/utmp hasn’t been initial ized correctly) shutdown will be called, which might not be what you want. Use the -f flag if you want to do a hard halt or reboot.
Does it change my advice? No.
Firstly, ESX 3.x still uses the old style reboot command and doesn’t link to shutdown (as Greg points out the comments, this change was actually made much earlier on) . Secondly, if your anything like me you are logging into a mix of unix/linux style command lines on servers, SANs, etc; you don’t want to guess what their version of reboot does. Thirdly, I’d still argue that
shutdown -r +1 “*** reboot for RAM upgrade by Forbes ***”
is still a better habit to get into.
- It allows other users to finish what they are doing or ask you to postpone things.
- It let’s you cancel the shutdown if you’ve made a boob (remember that sinking feeling in your stomach the last time you realized you’d just shutdown the wrong server).
- It writes a message explaining why, so you can track the reboots.
Lastly, if you’ve read this far and survived or re-visited for the update, here is an extra tip for you. Try this at the command line:
last -x|grep -e shutdown -e reboot
That has not been my experience in Debian and CentOS. The following is the same on both Debian Unstable (sid) and CentOS 5.3
# which reboot
/sbin/reboot
# file /sbin/reboot
/sbin/reboot: symbolic link to `halt’
When you “man halt” (or “man reboot”), you will find the following paragraph in both distributions:
If halt or reboot is called when the system is not in runlevel 0 or 6, in other words when it’s running normally, shutdown will be invoked instead (with the -h or -r flag). For more info see the shutdown(8) manpage.
Hi Andrew,
I agree things are changing. A lot of the latest versions of distributions symlink reboot to shutdown -r (presumably for the reason I stated above). Also Debian is moving to Upstart (from the older init system), so all the old commands are just links to replicate the functionality.
I’m fairly sure the advice is valid for the ESX 3.0 and 3.5 Service Console. Can anyone tell us how this is set on ESX 4.0 hosts?
Actually, the “older sysvinit releases” referenced in the man page are _much_ older than ESX 3. The Service Console in ESX 3 is a close relative of RHEL3. On RHEL3 (and ESX3) you have SysVinit 2.85, on RHEL5 (as on ESX4) you have SysVinit 2.86. The change happened long before that: version 2.54, in january 1995 (cfr /usr/share/doc/SysVinit*/ChangeLog
The reason not many ESX admins realize the “danger” of running reboot is that they use systems (like ESX) that aren’t that old, and that have the “safe” behaviour that we’ve known for more than 10 years now: reboot, init 0/6, halt, poweroff, and shutdown all cleanly shut down the system. Only caveat is: don’t add unnecessary options like -f or -n: those _are_ dangerous !.
cheers,
Bert.
Hi Bert,
Thanks for the info. I’m happy to put my hand up when I’m wrong, so I’ll edit the page. You’re making me feel old 😉
I guess I’ll still use the shutdown command, as at least I know where I stand.
init 6 and shutdown -r does the same thing from the unix/linux standpoint. It is not harmful to use those 2 commands at all. It gracefully restarts the linux/unix system. Sometime it is also good to do a sync command to flush the cache buffers right before running these commands.
Folks…good thread…what exactly does last -x | grep -e showdown -e reboot do?
Hi jsd,
last -x searches though the /var/log/wtmp and cats out all the entries related to run-level changes. So the whole command should tell you when the server was last shutdown or reboot. (I’ve corrected the showdown typo :))
Great article man! I never paid attention to the difference between reboot and init 6 command.
Thanks for sharing.
thanks man, now I know what and who accidently ruined my timesten database ^^