Topic: Is it necessary to reboot after applying U5?

[Matt]

I want to apply the latest updates to 5.6. Is it -really- necessary to reboot the server?

[Ray Mitchell]

That's what the instructions say !!

Regs
Ray

[Matt]

Yes, I know that.

What I'm implying in my question is whether it is necessary to take the somewhat drastic step of rebooting a loaded, hard working production server when the possibility of restarting appropriate services in correct order could result in the same thing.

[Terry]

What's the big deal about rebooting?  Does it prove some man thing point I'm not aware of?  I know I replied to the "uptime" thread with 2 servers that have decent uptimes, but that's cause they're servers that don't do any real world work except for testing and playing, they protect a network (each) of a couple of machines that hold no corporate important data.  My personal home server has a uptime of less then 10 days, does that make it any less of a firewall?  If the instructiuons say reboot it, then do so!

[Charlie Brady]

Matt wrote:

> What I'm implying in my question is whether it is necessary
> to take the somewhat drastic step of rebooting a loaded, hard
> working production server when the possibility of restarting
> appropriate services in correct order could result in the
> same thing.

It's strictly only necessary to reboot if the kernel has been upgraded (and perhaps if glibc has). Following the instruction provided will reconfigure and restart all services for any change. If you understand what has changed, you can work out the correct sequence of commands to reconfigure and restart only services which have changed.

Charlie

[Matt]

Terry wrote:
>
> What's the big deal about rebooting?  ...  If
> the instructiuons say reboot it, then do so!

Go and work for Microsoft if that's your attitude. There's a difference between what's necessary and what's recommended. Microsoft support recommends a reboot or reinstall whenever they don't understand what's happening or simply because they think it's the easy way out. Neither is usually necessary.

Further, I guess you've never had a server where the disks fail to spin back up after a cold boot. One server here had an utterly reliable RAID storage subsystem until it was taken down for a memory and processor upgrade. The disks that had been happily spinning for the last few years didn't want to play ball and fire back up. The entire set of disks had to be replaced. The server was down for a day rather than an hour. How much flak can you endure from those relying upon a service when it's your fault that you didn't have contingencies prepared?

As it stands, we are not prepared to take risks unless it is the only course available to us. That risk is a failure on reboot. If the reboot can be avoided the risk can be avoided and that is the path that will be taken.

It's easy to see when you take your head out of your backside and think things through. Of course, you can always rely upon someone else's thoughts, such as you do when blindly following instructions such as you have advocated.

This is our server, not yours. You treat yours the way you please. We'll treat ours with a bit more careful consideration.

[Terry]

Matt wrote:
>
> Go and work for Microsoft if that's your attitude.

I do maintain MS servers, and they reboot fine.
 
> Further, I guess you've never had a server where the disks
> fail to spin back up after a cold boot.
>How much flak can you endure from those relying upon a
> service when it's your fault that you didn't have
> contingencies prepared?

Nope, never had a disk not spin back up.  Maybe you should look into better hardware.  And I do have a contingency plan, it's called a backup, and a recovery procedure that has actually been tested.

> As it stands, we are not prepared to take risks unless it is
> the only course available to us. That risk is a failure on
> reboot. If the reboot can be avoided the risk can be avoided
> and that is the path that will be taken.

As Charlie said, if you know the order to restart services knock yerself out and do it.

> It's easy to see when you take your head out of your backside
> and think things through. Of course, you can always rely upon
> someone else's thoughts, such as you do when blindly
> following instructions such as you have advocated.

I'm following the maufactures recommendation, is there a problem with that?

[Matt]

Terry wrote:
>
> Nope, never had a disk not spin back up.  Maybe you should
> look into better hardware.  

Then you've never had a server with truly outrageous uptime. As for hardware, it doesn't get any better than top of the line RAID subsystems with the largest and fastest SCSI drives money can buy at the time of commissioning. It's a common issue with long term RAID subsystems. Drive bearings are fine when in motion but upon cessation of movement become frozen.

> And I do have a contingency plan,
> it's called a backup, and a recovery procedure that has
> actually been tested.

Sentences don't begin with 'and'.

Having tested backups and procedures is a given. What's the point of backups and procedures if you don't have hardware? How many spare drives are on your shelf? How many RAID controllers? How many DIMMs? How many processors? How much hardware do you have to put all that software back onto? That's why you don't do uneccessary serious things to running systems. Reboots are serious things. Do you factor the response time + 50% written into the hardware support contract when doing a planned reboot? I doubt you do.

> I'm following the maufactures recommendation, is there a
> problem with that?

manufacturer's != manufactures

The problem is obvious when reading the proposition. It's called initiative. Rebooting a server when it isn't absolutely necessary is just plain poor administration.

[Harold]

Matt wrote:

> Rebooting a server when it isn't absolutely necessary is just plain poor
> administration.

So don't do it - nobody's making you.

OTOH, if you wish to research each update and publish specific instructions as to how to fully and safely upgrade without rebooting, then please go ahead - nobody's stopping you.

H