Jump to content

When in doubt, reboot? Not Unix boxes


Recommended Posts


February 21, 2011

When in doubt, reboot? Not Unix boxes

Rebooting Windows boxes is a way of life, but rebooting by default can you get you nowhere fast when running Unix

Last week, I wrote a little item titled "Nine traits of the veteran Unix admin." Had I known that a few hundred thousand people would read it in just a few days, I might have put on a clean shirt or something. Regardless, I'm sorry I stopped at nine. I had at least fifteen, but it was already a long post.

The most interesting aspect of the feedback I received was that the vast majority of readers agreed with me on just about every point -- with the exception of the first and last items: sudo and reboots. (There were also a few folks who hammered me for not including vi in favor of vim -- I did! And who thought that because I referenced Perl briefly, I hadn't ever used bash or some such nonsense?)

[ Also on InfoWorld: Read Paul Venezia's Deep Dive PDF on virtualization networking. | Check out Paul Venezia's five-year plan to tackle the 8 problems IT must solve. ]

I want to take a closer look at the reboot issue. It's a hot spot for all server admins, but to Unix geeks, it's a deeper issue -- probably because Windows admins use reboots as one of their first troubleshooting steps, while it's one of the last for the Unix team.

Here's the reality: Server reboots should be rare -- very rare. I cited kernel updates and hardware replacement as the two leading causes of reboots in the Unix world. Some have mentioned significant security risks in not rebooting servers, but that's nonsense. If there's a security risk present in a service or application, a patch can be applied without requiring a reboot. If the security risk is present in a kernel module, it's generally possible to unload the module, apply a patch, and reload the module. Yes, as I said, you need to reboot if there's a security risk in the kernel. Otherwise, there's no real reason to reboot a Unix box.

Some argued that other risks arise if you don't reboot, such as the possibility certain critical services aren't set to start at boot, which can cause problems. This is true, but it shouldn't be an issue if you're a good admin. Forgetting to set service startup parameters is a rookie mistake. Naturally, if you're building the box and it's not in production, you can do all the reboot tests you want without adverse effects. That's just good practice.

But there's another side: Those who consider reboots to be a worthy troubleshooting step are going to get themselves in trouble sooner rather than later. Let's say a Unix box has gone wonky. A few services that were running will no longer start, maybe with a segfault, and other oddities abound.

next page

Link to post
Share on other sites

  • Root Admin

Well Windows is getting better at it but is not quite there yet for in-use file replacement. However I've personally done Unix admin work about 10 years ago and there are times when the box can lock up just like a Windows box and you have no choice but to reboot.

If any Windows Admin is simply rebooting to fix a problem then they too are a rookie as he stated about the Unix admins. One should attempt to determine what is really going on and if possible fix it without a reboot. The monthly updates from Microsoft are typically the only cause for my server reboots, not due to something that could not be fixed without a reboot. Though I do have one Windows Server that cannot be accessed by any outside or inside means of Malware and it was up and running for over a year until we had to move it.

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    • No registered users viewing this page.
Back to top
  • Create New...

Important Information

This site uses cookies - We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.