an OS question

[cellio]

While waiting for assorted software updates to install today I found myself wondering... Mac OS and Windows usually need to reboot your machine to install updates. Yet I have, several times, seen Unix machines that I believe were being maintained with uptimes of more than a year. What's the deal? Is Unix just better able to support hot-fixes, or are Unix updates that rare? (Or am I wrong about the maintenance of those machines?) And if it's that Unix is better at updating, why does Mac OS, which is Unix-based, need to reboot so often? Mind, it's definitely better in this regard than when I was running Windows; this is a puzzle, not a rant.

Edit: Thanks for the comments thus far. I now understand more about how Unix is put together, and why Windows is different. Still not sure about Mac OS but comments suggest it could be UI-related (that is, the GUI might be more tied into the OS than is the case on Unix).

Comments

[rjmccall.livejournal.com]

Almost all software updates require changes to code. That code might be in the kernel, in a dynamic library, or in a program binary. The update either has to hot-patch currently running code — more about this later — or it has to shut down everything which has that code loaded. That's impossible for the kernel, of course, and relatively painless for programs unless they're system daemons. Thus the major issue is dynamic libraries. Command-line programs tend to have relatively few dylib dependencies (other than the C/C++ standard libraries), so a box which doesn't run a GUI (or can drop out of its GUI) can usually patch most of the system without needing to technically reboot. A GUI program, on the other hand, tends to have dozens of different dynamic libraries loaded at once — many more on Mac OS, which takes this to extremes — and so it's much easier to just reboot the GUI, which usually means the system.

The alternative, hot-patching, is pretty risky and takes a lot of QA resources, which is why Microsoft has started using it heavily but everybody else is a bit gun-shy. There's a fun attribute (__hotpatch, I think) the MS compilers let you pepper onto functions; it requests that the function be laid out in memory in a particular way which permits the first instruction to be atomically overwritten with a near jump to a scratch buffer containing a far jump to some replacement code. If there's a security problem in a single function, that makes it pretty easy to fix a DLL in memory, and then it gets fixed properly on reboot.

[brokengoose.livejournal.com]

Some mission-critical Unix systems can be hotpatched, too -- even kernels. (See ksplice for Linux for one example).

It's a hassle, and it can bite you later during the "see if it reboots cleanly" stage of your next maintenance window, but it can be useful if availability really matters.

(This can mean, in some environments, that development or QA servers are hotpatched, too, so that they mirror the production servers as closely as possible.)

[rjmccall.livejournal.com]

Neat. ksplice looks to be relatively heavyweight compared to MS hotpatching, since it requires briefly halting everything except ksplice; but I doubt it makes much difference in practice; the length of actual downtime should be brief unless it actually needs to update data structures, which is not something MS's hotpatching makes any easier.