Unix: Where shutdowns are not disasters

Unlike federal shutdowns, Unix shutdowns (and reboots) are generally smooth and easy, don't cost $24B and leave the system in better shape.

In the wake of the federal shutdown, I can't help but spend a little time reminiscing about how easily and non-traumatically Unix systems generally shut down ... and reboot. No tens of billions of dollars lost from the economy. No sturm und drang about what gets funded. A planned reboot of a Unix system is often a healthy operation that can help to ensure that your system is running smoothly and that required services are configured properly. After a successful reboot, you can feel more confident that your Unix system can be restarted without unexpected consequences any time you may feel the need.

You can shut down a Unix system immediately or at some specified time. You can shut down and power down or shut down and reboot. You can even schedule a shutdown to occur using a crontab entry, though you'd need to be very careful to avoid an unintended recurrence next month, next year or the next time February 19th falls on a Saturday.

The Unix shutdown command provides a way to shut down a system in a smooth and orderly way. Services are stopped in the proper sequence, given time to close connections to files, and generally there are no bad side effects. A planned reboot might give you and opportunity to work on hardware -- add memory, replace a drive, etc. -- or might just ensure that your system processes are all working in sync. A planned reboot after upgrading a complex application can leave you confident that your configuration is working and that unintended reboots are unlikely to be painful.

The primary shutdown command is shutdown -h now. This shutdown command will halt the system after properly shutting down all processes.

# shutdown -h now

Broadcast message from cruz@system12

The system is going down for halt NOW!

That said, however, whenever a system must be rebooted during work hours -- or any time users are likely to be logged in or running tasks that they will expect to finish -- you should provide a warning. You can do this by emailing your users or by providing a warning as part of your shutdown command. Keep in mind that user processes might be running even when your users are away from their desks or home sleeping. Give as much notice as you can.

In this command, we're shutting down a system immediately, but sending a message to anyone logged in and active so that they understand what is going on.

# shutdown -h now 'System is going down for emergency disk replacement'

To reboot a Unix system immediately, you can use the shutdown -r now command.

# shutdown -r now 'Emergency reboot'

To shut down a system at 10 PM, you can use a command like this:

# shutdown -h 22:00

The Unix shutdown command even provides an option to cancel a shutdown (shutdown -c) that you can use to stop a shutdown that you've already set in motion, presumably because you realize it isn't necessary or have decided to postpone the shutdown until some later time.

Very infrequently, I have used a crontab entry to shut down a system. For example, if I want the system to shut down prior to a power outage, but am not sure that I'll be available on a Saturday night at midnight. I might use a very specific cron entry to do the reboot for me. But I will be, in cases like this, very specific about the timing. For example, I might schedule the shutdown to occur at midnight on a specific date and day-of-week:

0 0 1 10 1 /sbin/shutdown -h now

This would shut down and halt the system on September 30th at midnight (October 1st a 0:00 AM) if it's a Monday. This leaves me plenty of time to remove this command before it will try to run again. I could use an at command if I set up the command in close proximity to the activate time.

If you want to allow a particular user the privilege of shutting down a system, you have a couple of options. You can add their name to the /etc/shutdown.allow file or you can provide this option using the sudoers file. I have sometimes given this privilege to developers who, assigned a system for their own personal development efforts, sometimes need to reboot a system and shouldn't need to wait for my attention to do this for them.

Cmnd_Alias	REBOOT = /usr/bin/reboot, /sbin/shutdown
...
jdoe		ALL = REBOOT

Options to the shutdown command include (but check your man command):

  • -a Use /etc/shutdown.allow.
  • -t sec Tell init to wait sec seconds between sending processes the warning and the kill signal, before changing to another runlevel.
  • -k Don't really shut down; only send the warning messages to everybody.
  • -r Reboot after shutdown.
  • -h Halt or poweroff after shutdown.
  • -H Halt action is to halt or drop into boot monitor on systems that support it.
  • -P Halt action is to turn off the power.
  • -n [DEPRECATED] Don't call init(8) to do the shutdown but do it ourselves. The use of this option is discouraged, and its results are not always what you'd expect.
  • -f Skip fsck on reboot.
  • -F Force fsck on reboot.
  • -c Cancel an already running shutdown. With this option it is of course not possible to give the time argument, but you can enter a explanatory message on the command line that will be sent to all users.
  • time when to shut down

I have worked on Unix systems that hadn't rebooted in many years, but this is not common, especially when systems are supporting complex applications or are in data centers that from time to time undergo power outages. Being ready to shut down or reboot a Unix server is a fundamental Unix skill and, unlike the federal shutdown, isn't likely to have repercussions that trouble you afterwards.

What’s wrong? The new clean desk test
Join the discussion
Be the first to comment on this article. Our Commenting Policies