Fog Creek Software
Discussion Board




Why does Windows need to reboot after patching?

A cynic wrote:

> As an aside, in my experience the biggest issue with patching MS systems is that often a reboot is required, whereas UNIX-like systems you can get away with just starting & stopping the service / daemon.

... and I was wondering why that is so.

As an aside:

* I've written device drivers that you can install and start and stop without restarting the O/S; it isn't difficult.
* Perhaps a reboot is often required, but it isn't always; sometimes I am not told to reboot after I install a Windows patch.

I'm guessing that the answer is that Windows needs to be restarted iff a DLL such as USER32.DLL or KERNL32.DLL changes. It needs to be rebooted, because every running Win32 application (including the Explorer/desktop, and including the login screen) is using these DLLs. These applications won't start to use the new DLL until they're restarted, and the easiest way to restart them is to reboot the entire O/S.

Also, most Windows services are user-mode Win32 services, not kernel-mode NT device drivers. Therefore, most services need to restart after a change to a Win32 system (so there's no point in just restarting Win32 while leaving the NT kernel running).

Is this the reason why a Windows restart is necessary?

And, what's different about the Unix architecture that means this doesn't apply to Unix? Is it simply that there is no Win32 subsystem, and that any Win32-subsystem-like functionality is in the Unix kernel, and applications/daemons link directly to the kernel?

Lastly, why the fuss about rebooting? I can vaguely imagine how to go about writing code to swap versions of e.g. KERNL32.DLL while applications are running; it might be difficult to write, and you might need to pause the applications; but not generally impossible. But perhaps it isn't worth MS's while to implement that: if you need service uptime, then don't you get this by running a cluster and rebooting different machines at different times?

Christopher Wells
Tuesday, June 01, 2004

"Is this the reason why a Windows restart is necessary?"

The are really two reasons a reboot might be necessary:

1. Some system configuration changed that needs to be re-read;

2. Some in-use file(s) had to be replaced, so a reboot is required to get them replaced.

Microsoft has worked to eliminate a lot of the unecessary reboots casued by #1 (for instance, in the old days, networking config changes required reboots... yuck).

In the case of #2, it's pretty tough to get around the need to reboot. One could say that the user/admin can mitigate this by killing all apps and stopping any unnecessary services. Most people prefer to just let the patch roll and then reboot, rather than shut everything down first.

Brad Wilson (dotnetguy.techieswithcats.com)
Tuesday, June 01, 2004

They did the simplest thing that could possibly work.

son of parnas
Tuesday, June 01, 2004

And fixed it when their customers complained. The system worked just fine. :)

Brad Wilson (dotnetguy.techieswithcats.com)
Tuesday, June 01, 2004

Larry Osterman touched on this since he develops winmm.dll http://weblogs.asp.net/larryosterman/archive/2004/05/13/131263.aspx

Have a read of some of the comments.

Peter Ibbotson
Tuesday, June 01, 2004

I'm also curious about the anti-reboot mania for the exact reasons you state. What makes it even more curious is that AFAIK linux/unix types are generally really, really good about making sure their machines can reboot cleanly and come up right every time (while traditionally us Windows types have taken a "okay, it's working, don't touch it" approach)

As you said - if five minutes of downtime is so very critical, then shouldn't you have multiple servers and round-robin them?

Just wonderin'

Philo

Philo
Tuesday, June 01, 2004

Philo, you are missing the point.

It's not about 5 minutes of downtime.  It's about anywhere from 5-15 minutes of downtime, repeatedly.

We are a small shop, but we can't have downtime in the middle of the day.  Every time that heap of crap machine goes down for a reboot, that means I'm awake at 1AM, and I don't like being awake at 1AM at all.

The major issues here is that a server-grade OS should have licked this problem. There is simply very little in userland that should require the machine to go down for a reboot.

Admit and accept the *fact* that Windows was *never designed* to be an industrial computing platform, but rather happened there by virtue of marketing, and the whole thing becomes much more acceptable.

Sassy
Tuesday, June 01, 2004

Windows has detected that you have moved your mouse.  Please reboot for this change to take effect.

[Reboot Now]  [Reboot Later]

Should be working
Tuesday, June 01, 2004

"Admit and accept the *fact* that Windows was *never designed* to be an industrial computing platform, but rather happened there by virtue of marketing, and the whole thing becomes much more acceptable."

I bet you daren't say that to Dave Cutler's face.

John Topley (www.johntopley.com)
Tuesday, June 01, 2004

"We are a small shop, but we can't have downtime in the middle of the day.  Every time that heap of crap machine goes down for a reboot, that means I'm awake at 1AM, and I don't like being awake at 1AM at all."

Wow. So you patch production servers in the middle of the day? Or you let them autopatch unattended in the middle of the night?

Seems to me that if you need patches, you're gonna be up at 1am whether the box needs rebooting or not. I know *I* was always up for a patch, even when it was just replacing an HTML file.
And when you consider the overhead to patching (preparation, verification, patch, test, verify, log), then another five minutes for a reboot is incremental, not significant.

Hold the phone... Shouldn't a reboot be part of any major patch *anyway*? Test all major functions after a patch, right? One major function should be "comes back up normally after reboot" - if something about the patch affects the service/daemon/application starting, then you need to find out when you're in patch mode, not when the ISP bounces the grid and your UPS dies while you're in Topeka...

Am I missing something?

Philo

Philo
Tuesday, June 01, 2004

"Shouldn't a reboot be part of any major patch *anyway*?"

Not unless I'm patching the kernel...  which, of course, I'd have to reboot for anyway.  Although there is some work being done on Linux right now to replace a currently running kernel with another version.  ;)

"One major function should be "comes back up normally after reboot""

In the Unix world, a reboot is a less significant event.  If can I start a daemon from the command line then it'll start on reboot -- there isn't any sigificant difference.

"Am I missing something?"

Rebooting involves shutting everything down and hoping that it'll come back up.  When working with remote systems, that could be troublesome.  If I'm patching Apache -- there is no reason to shutdown email, ssh, the database, etc.  If I'm patching the database, then I can leave Apache running with a nice "we are updating our database -- come back soon" message.

The main reason that reboots are required on Windows is that everything is so interrelated.  On unix, everything is more independent. 

Almost Anonymous
Tuesday, June 01, 2004

"Rebooting involves shutting everything down and hoping that it'll come back up.  When working with remote systems, that could be troublesome. "

to me thats the killer point.  we make sure _all_ our remotely controllable clients machines are running some sort of Unix (ok, ok, they are all running osx, but thats just cause its what I know best)

Having a clients machine fail to restart is a real PITA, and it can happen all too frequently if you are forced to reboot as often as you are on windows.

To me the biggest issue in windows is the interdependence of every element on every other, it makes things....messy....

FullNameRequired
Tuesday, June 01, 2004

It's not even just OS patches that require rebooting in Windows.  >50% of applications and drivers also require a reboot after installation.

Maybe the application developers could have written their apps in such a way that a reboot would not be required, but apparently the way Windows is designed makes it very difficult for them to do so.  Otherwise rebooting after installing an app would not be so common.

T. Norman
Tuesday, June 01, 2004

"Wow. So you patch production servers in the middle of the day? Or you let them autopatch unattended in the middle of the night?"

We never autopatch anything, are you kidding me?  No, someone drinks a lot of coffee, stays up, and patches the machines.  This happens a lot more often with our Win machines than our *nix machines.

Sassy
Tuesday, June 01, 2004

There is a major difference between Windows and Unix in this regard: Windows cannot replace files that are in use; it needs to schedule those replacements to the next reboot.

Unix on the other hand has no problem replacing files that are in use. The old version is kept on disk (I think) and in memory as long as at least one process has that file open. Processes that open the file after it has been replaced, get the new version.

You can easily try it, for example, in the context of compiling and linking: in Windows, open Visual Studio, create a simple program (or open an existing project), compile & run. While it's still running, make a change and compile again. The linking stage will fail, since it can't write it output. The same in Unix: code a simple program, build it, run it, build again while still running. Run the new executable, and now you have two processes running different versions of the same file. Once the first process is done, the old version is discarded.

vrt3
Tuesday, June 01, 2004

I have to say that MS has made a lot of progress on this over the years. It used to be that you basically had to reboot for every app install, no matter what. Now, you typically don't need to except for security patches, that, for all i can tell, affect the OS directly.

Any of the griping about instability, etc is completly on target for Win9x but the NT line is a different animal all together.

MilesArcher
Tuesday, June 01, 2004

Philo - since I indirectly started this thread perhaps I can explain the "anti-reboot mania".  The network I run has a couple of Windows servers (1 SBS 4.5, 1 NT4sp6 - both due for replacement) about 15 desktops and 2 SnapServers.  The SBS server provides all e-mail, web access and network logon whilst the NT4 server runs our membership database which we use for all membership services, accounts and events bookings. Not a great deal of room for multiple servers.

Once a month we get the patches.  With the desktops it's easy enough to update while people are at lunch; but with the servers I either have to stay late or plan downtime (at a minimum of about 5 mins per patch) which as you can see impacts everybody. 

Result - it's not fatal, it doesn't stop me patching but it is a pain in the arse.  Most importantly, in my opinion any disincentive to keeping your systems up to date is bad news.

Finally, lest you feel picked on, as far as I'm concerned this isn't Microsoft bashing - it's customer feedback. Which I'm happy to say appears to be being addressed, as Brad Wilson pointed out.

a cynic writes...
Tuesday, June 01, 2004

Cynic - I don't feel it's bashing; I really appreciate the feedback and information in this thread, and I thank the participants for keeping it civil. :-)

As for staying after being a pain - yes it is, but from my management I have to say "goes with the job." Basically, being a sysadmin should always mean that at least 1-2 days a month you're going to be working after hours (and the job should pay appropriately).

"Having a clients machine fail to restart is a real PITA, and it can happen all too frequently if you are forced to reboot as often as you are on windows."

Just for the record, I ran five systems in Chicago and two in Maryland for two years - I never had any reboot issues. Yes, I had to reboot on occasion, but they always came back up. The only mandatory onsites I had were when I worked on the firewall (since one screwup there left no room for forgiveness)

Philo

Philo
Tuesday, June 01, 2004

"Just for the record, I ran five systems in Chicago and two in Maryland for two years - I never had any reboot issues. Yes, I had to reboot on occasion, but they always came back up."


FWIW Im sure thats true, so long as its all running fine.

<g> its the idea of the danger involved in a reboot thats as offputting as the actual risk.....how often does it have to occur before its too often?

When I first started I was working for another place that remotely  controlled several windows machines, running win2k (IIRC)
They were part of a distributed database system and we remotely controlled them with pcanywhere.

rebooting was a gamble :)  it was found to be necessary on a fairly frequent basis (once or twice a month) to stop the servers grinding to a halt, but there was a chance that the reboot would fail and we'd be left hanging in the air.
This wasn't 'common' as such, maybe 1 in 10 reboots, but it was a real statistical possibility.
<g> and given that they had approx 10-20 servers, all of which had to be restarted bi-monthly to be sure there was a minimum of downtime, that possibility quickly became a statistical certainty.

it was both a minor thing (1 phone call and their admin person would go and perform a manual restart)
and a pita, sometimes they weren't there and we'd have to give directions and descriptions of various computers to the person who was there....there would still be an even chance they would reboot the wrong machine or unplug the keyboard instead.

<g> and once or twice we had a wonderful time when the person rebooting had caps lock on and so the password wouldn't work for no apparent reason.

and Im not even going to go into the necessity of having all sorts of randomly selected people at their end having to know and enter the passwords to get us back up.

also of course if it occured outside of business hours then we were just plain stuck until somone came in...no biggie at 3am monday night, but occasionallly a real killer at 6:30 pm on a friday, we could potentially lose an entire weekend.

So even though their data or system wasn't in immediate danger as such (we had enough redundancy that I dont think any actual downtime occured, although it was real close once or twice) it was _still_ enough to give me a ringing dislike of windows being used in that situation.

even accepting that XP is prolly improved , Ive _already switched_ to using unixy type OS's in those situations and there is no real reason for me to switch back ever.  Ive had no problems whatsoever with them.  None at all.  nada. zip. zero.

<shrug> for various reasons it obviously wasn't an ideal setup anyway, but at the same time it has given me an inbuilt repulsion against rebooting except when its absolutely necessary.

FullNameRequired
Tuesday, June 01, 2004

Amen.

Sassy
Tuesday, June 01, 2004

oh, just as an addendum.

Someone Who Should Be Working has just reminded me that in this particular case the regular reboots required to keep the servers running were eventually discovered not to be the (direct) fault of the operating system, but the fault of the hardware setup.

Bloody hardware was gradually overheating, one machine at a time.


the point of the story was, of course, to help philo understand my instinctive dislike of rebooting, not to put down windows as an operating system :)

FullNameRequired
Tuesday, June 01, 2004

ok, ok.  not the hardware overheating directly but some odd incompatibility between the RAID system, the database, the web server and the filesystem of the computers themselves all of which disappeared once the client moved all of their computers into a properly ventilated and maintained area.


Its worth noting that in future correcting a post I make to JoS will be taken as admitting that you were browsing when you should have been working, and that therefore you are at the same time formally requesting the rest of the afternoon off (unpaid).

FullNameRequired
Tuesday, June 01, 2004

"it was both a minor thing (1 phone call and their admin person would go and perform a manual restart)
and a pita, sometimes they weren't there and we'd have to give directions and descriptions of various computers to the person who was there.."

You could've avoided all of this by getting an IP controllable UPS - then you just pop the power remotely. (I had to do that when one of our systems had a hardware compatibility problem and needed to be bounced every few days until we found the problem)

Why did the support personnel need to log in? My systems all ran services - no login necessary; boot it up and it runs.

And why did you have the boxes at a data center that wasn't manned 24/7? [grin]

Finally, you needed to reboot the systems because of hardware faults, and sometimes they didn't come up because of hardware faults. IMHO this is par for the course and not a strike against having to reboot - if you have to reboot for a patch and the system doesn't come up due to a hardware fault, that's a problem with the system, not the OS. It's akin to having a known bug in your software that you don't fix hoping nobody will happen to perform that sequence of events.

I'm not trying to be confrontational, just pointing out that with any system there are things you do to protect yourself...

Philo

Philo
Tuesday, June 01, 2004

<snip>  yep, as I said, it wasn't exactly an ideal setup, there were a bunch of obvous improvements that could have been made right off.  I inherited the setup when I got the job and hadn't learnt enough to know how to push to have it fixed.

"And why did you have the boxes at a data center that wasn't manned 24/7? [grin] "

<g> stupid clients insisted on having stupid computers onsite for stupid reasons that I still do not understand.

"Finally, you needed to reboot the systems because of hardware faults, and sometimes they didn't come up because of hardware faults."

actually I dont agree with that diagnosis.  The servers would slow to a crawl with 100% CPU usage over time, a reboot would set them right as rain again.
The reboot failures were more often to do with various applications or services not quitting cleanly and the entire system hanging at that point.
Admittedly the 100% CPU issue disappeared once the clients rearranged the hardware and used a more professional setup but there was definitely more to the whole issue than met the eye.....
<g> whether its windows or the hardware that is blamed for that hang is _entirely_ irrelevant to the point of the story however.

"if you have to reboot for a patch and the system doesn't come up due to a hardware fault,"

yeah, as I said that wasn't what was happening.

The _point_ of my original post was that forcing a system admin to reboot a computer is a Bad Thing (tm)

<g> the long and somewhat boring story was an attempt to explain why this is the case, and to highlight some perfectly reasonable consequences of reboot failures.

I _never_ have to reboot my remote machines now _unless I choose to do so_

The power of that is huge, If I want to upgrade the actual OS
I can plan a reboot for 10:15 tuesday morning and have someone right there ready to smash the existing computer into dust with a sledgehammer if it fails to restart cleanly.

For anything less, no reboot is necessary (and my understanding is that even the osx reboot for upgrade is mostly unnecessary on Linux machines, ie, apple is also doing some unnecessary stuff when upgrading......I already have some time put aside later on in the year to try dropping in some Linux servers as replacements and see how they go)

What windows needs to be is _far_ more modular.  I dont want to reboot after installing a patch that repairs a hole in IE if the sodding machine never runs that program anyway.

FullNameRequired
Wednesday, June 02, 2004

"if you have to reboot for a patch and the system doesn't come up due to a hardware fault, that's a problem with the system, not the OS."

It is a problem with the hardware AND a problem with the OS.  If the OS didn't need to reboot because of the patch, the hardware problem would likely be a non-issue.

T. Norman
Wednesday, June 02, 2004

*  Recent Topics

*  Fog Creek Home