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

[richardf8]

I think a lot of it has to do with upkeep of the User Interface. Unix machines with long uptimes tend to be servers, and the GUI, if it is running at all, is not much being interacted with. Stopping a service, updating its executable, and restarting it is trivial. However, even on Unix boxes, once the packages involving the GUI get involved things get messy.

The Pretty - it costs.

[cellio]

Hmm, good point. The only user interface I use on Unix machines these days is the shell. (In the past, also X-Windows.)

[asim.livejournal.com]

Servers like that aren't (usually) updating their kernels. The Unix OS design is such that there's very little tied to the kernel in ways that they are in Windows, so unless you have one of a handful of apps, you rarely need to reboot to install. There's no hot-fix capacity in Linux, it's just that the kernel does so much less that the equivalent in Windows does. And even then, there's a new project to allow kernel updates w/o a reboot, but that's in early days, yet.

Re: UI -- all you really have to do for these points, unless you're replaced the kernel-level video driver, is restart X. Part of why some Linux distributions have you restart is that they don't include a "restart X" capacity, but many Linux sysadmins know about that and how to trigger it.

Without having worked on Macs, I suspect the above, coupled with the tight coupling Darwin (the kernel for Mac OSX) does between it and the UI, is why Macs reboot so often. But yes, it's mostly about loosely-coupled pieces, and what that can buy you.

[http://users.livejournal.com/merle_/]

I agree. Back in the Linux 0.91 days I was rebooting constantly because I patched the kernel every night. These days, I live with what I have, because the apps are mostly independent (and daily builds were a pain). My work desktop is still running RHEL3. Why upgrade? I only use it for terminal windows, it's behind a firewall behind a VPN behind another firewall.

[geekosaur]

OSX / Darwin has an additional little feature: it prelinks shared objects so they can be fast-loaded at non-conflicting addresses for most processes. The gotcha is, if a prelinked object is modified and then used before the prelink cache is generated again (as by an install while the system is running), Bad Things happen. (It's been known to require a complete reinstall to recover.) So starting in 10.5 Apple made most installs require reboots, specifically to insure that the prelink cache remains valid.

# # #

Many Linux/Unix admins don't want to reboot, hoping that the occasional (or not-so-occasional) kernel-based security hole won't affect them. I tend to consider that a bad idea these days.

That said, there's a (for-pay, although IIRC some distribution (Ubuntu?) has a reduced functionality version available to all registered users) technology called Ksplice that can patch a running kernel in many (most? all? haven't looked closely but I think the latter is impossible for logistical reasons) cases. It's been around for long enough that there could well be some Linux boxes with uptime > 1 year that use it to keep the kernel up to date on patches.

[dragonazure.livejournal.com]

Its been a long time since I did any operating systems work, but from what I remember, it largely depends on the type of update. In UNIX, I haven't seen/been involved in a major upgrade in ages, but usually, only services and device drivers get updated and that doesn't require restarting the entire system--just "refreshing" the services. A serious upgrade to the OS kernel will generally require restarting the system. If you have to have to reconfigure your system settings, that also usually requires a restart of the system, but I don't think that is what you are asking....

With Windows, I suspect that certain things are still very closely coupled to the operating system kernel. If I were a little more paranoid/cynical, I might think it is also a sneaky way to mask memory leaks and garbage collection problems.... 8^) To be honest, I do get a lot of Windows "hot-fixes" at work, but I suspect they simply are patches and upgrades to non-core components of the system (or what passses for TSRs these days)

[cellio]

I get lots of updates at work too (where I am currently using XP), but I usually can't tell which are OS upgrades and which are application-level stuff that our IT department has decided we need. We just get a generic message about updates (and instructions to reboot).

[dsrtao]

Hi, I run Linux and NetBSD servers for a financial software-as-a-service company that you have not heard of (unless you are a bank, brokerage or RIA). I also manage the desktop infrastructure, which includes Windows and MacOS boxen.

We have updates to various software packages all the time. Mostly we test these, batch them up, and install during maintenance windows. It is very rare to require a reboot, because pretty much the only thing that requires a reboot to replace is the kernel itself. Now, kernels get updates -- but a non-public, no-shell-users machine that is hidden behind a firewall may see a required update rather less than once a year.

That said, our boxes tend to be up for less than a year at a time simply because not all of them have redundant power supplies, and so our annual re-cabling and box-moving day causes them to be shut down. We have a utility box with dual power supplies which has an uptime nearing four years... it may be shut down only when it has a hardware failure or we need beefier hardware.

[goldsquare.livejournal.com]

Of course, when it comes to this stuff, dsrtao is correct at all times.

To expand slightly: it was part of the original design theory of the UNIX kernel that the kernel be responsible in largest part only for the management of memory, the running of processes, and the calling of device drivers. As much as possible of the standard operating system services is to be run outside the kernel as can be. That's why the many comments about "patching the kernel" imply that it is so rare. It's very rare.

In older days, replacing device drivers required compiling them into the kernel and rebooting. Some 25 or so years ago (maybe a touch more), the standard kernels were reconfigured and rewritten to allow the dynamic loading and unloading of device drivers.

Some years ago, the Mach project (an UNIX OS off-shoot) tried to make the kernel as small as possible, and many of its designs were reflected and re-absorbed back into the modern UNIX/Linux family of systems.

Windows is megalithic. UNIX (and its children, primarily Linux) are small and intended to be so. I could not tell you with authority why it is that the MacOS system (which is based upon a Berkeley UNIX system) requires reboots. I suspect it is either that the kernel is often patched -OR- that there is something running alongside the kernel that requires a reboot, and is very proprietary.

[sethg]

I don’t know about Mac OS, but aside from what others have said above, there is a specific difference between Windows and Unix-family filesytems that is relevant here.

In Unix filesystems, there is a level of indirection between a file’s name and its inode, which contains things like the ownership, permissions, and pointers to the blocks storing the actual data on the disk. Because of this indirection, one process can open a file, another process can delete it, and the storage the file uses will not actually be freed up until the first process closes it.

In Windows, back in the day, such was not the case: if one process had a file open another could not delete it. (I am using the past tense here because I just tried doing that with Windows 7 and I succeeded. Maybe NTFS has finally caught up with the 1970s, or maybe the user interface just removes the icon from the desktop without actually deleting anything.) So if an upgrade had to modify some file that the OS needed to keep open, then the only way to accomplish the upgrade was to shut down the computer and swap in the new versions before the OS reopened them.

[cellio]

Oh! I hadn't made the connection about inodes, even though (1) I know what they are and (2) I've been frustrated by that complaint from Windows that some (unnamed, mysterious) process is using a file I want to delete. Yeah, that makes sense!

I'm currently on XP at work, though I understand that Windows 7 will be rolling out next year. I should be good until October, when the lease on my current machine expires, assuming nothing melts down that would require earlier replacement. (My goal is to be among the last to get it, not among the first. That's not specific to Windows 7; for any expensive transition, I want to be able to benefit from what others have learned, 'cause my deadlines aren't going to get pushed out just because I now have to figure out accessibility, security, and just plain usability in a new environment.)

[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.