Hacker News Reader

Comment by microtonal | Hacker News Reader

enterprises really hated that because it meant that sometimes 1000s of computers were all out of commission running updates at the same time.

If a computer has to go out of commission for a security update, you are doing it wrong (as an OS vendor). Doing cumulative updates is only band-aid. The real solution is make the OS modular and reliable enough to replace/restart components while it is running.

View on HN

To the downvoters: Red Hat, et al. can roll out security updates on running systems. Except for kernel updates, though kexec avoids long restarts.

This is a somewhat unpleasant semi-misconception. You can, indeed, update everything but the kernel without rebooting. In fact, I suspect you could even replace the kernel image and the modules while they're running (but this will certainly break any attempt to load modules at a later point without rebooting first). (Edit: most distributions choose to keep the old image along in case the new one breaks. It's relatively unfrequent now, but back in 2003...)

Generally, however, processes don't get restarted after updates and libraries don't get reloaded, so without rebooting, you're still running the unpatched versions.

I don't know if RHEL has a clever way to figure out what needs to be restarted (it's not entirely impossible, thanks to systemd), but pretty much everyone under "et al." has this problem.

See Peter Larsen's comment here: https://lwn.net/Articles/702664/ for a more authoritative take on this, I deserted to BSD land long ago...

tl;dr Rolling out the updates without restarting is one thing, and it's done, and Microsoft could do it too, they just take the easy route. Applying them without restarting is a very different and far murkier story.

An important part to me is that usual linux updates don't cause the next reboot to take longer, or require multiple reboots. You can install the update without rebooting; it only applies on the next reboot.

> Generally, however, processes don't get restarted after updates and libraries don't get reloaded, so without rebooting, you're still running the unpatched versions.

It's possible determine what processes run outdated library code. There are tools which hook into the package manager which do this, like https://github.com/liske/needrestart

Like I said, it's not entirely impossible (a while ago I was using checkrestart on my Debian machine with pretty good results), but the result is still somewhat clunky. There are a lot of things that aren't so easily checked: changes in interpreted code (needrestart can, fortunately, deal with Java, Perl, Python and Ruby, but I don't know how well, and there's no shortage of packages that rely on old-fashioned bash scripts or -- hey, Polkit! -- JavaScript), changes in configuration files and so on.

This is a reasonable solution if you're running relatively non-critical processes on a single machine. If you really want to avoid downtime, a cluster with rolling updates seems like a solution with far fewer headaches.

Non-critical covers a lot these days, fortunately :-).

Yes, clustering and virtualizing things is pretty much how this has been handled at a scale, be it modern web applications, (Open)VMS or mainframes. It's simpler and has other advantages to architect the application for this than to do the custom integration work required to make it work on a process/application level.

> (Open)VMS

It'll eventually get reinvented :-).

If memory serves, Microsoft cannot actually do it, due to differences in file system semantics. In Windows, it's not possible to replace a file that's in use.

Unfortunately, the last time I had to do system-level Windows programming was such a long time that all I remember are a bunch of things starting with hwndsomethingsomething, so I certainly don't remember if this is the case, nor the specifics (if I ever knew them, I was very young and therefore very stupid at the time).

However, the opposite problem - that of (thread-safely) ensuring that you're not stepping on another process' file when you're writing, wiping or moving it - is pretty tedious under Unix. The only way to do it reliably - that I know of - is via flock, which is opt-in and therefore not always an option (e.g. the other process is a third-party application that doesn't lock its files), and doesn't work on remote filesystems

There is no design decision without at least one compromise hanging on its tail.

Your memory is serving you incorrectly.

* https://news.ycombinator.com/item?id=11415366

Unlinking and replacing are not the same thing.

DLLs and other components installed system-wide are almost never the same file: Updates install new versions of most DLLs into the SxS system and compatible applications load newer versions when they are restarted.

Unless they bring their own version, something that has been a issue at least once.

Applying updates without degrading service has always been somehwat difficult to do; but it can be done in ways similar to "graceful reloading" that is relatively widely used in web servers. However, it requires custom integration work, which means you need a capable sysadmin and perhaps a developer or two to implement it, so usually you just don't. Clean restarts also avoids bugs that you might introduce there.

Even if that were the case, many enterprises would still want to perform testing before deployment or require updates to be part change management.

I could just as easily argue the opposite: If your operations can't handle individual system reboots you are doing it wrong. Rebooting and even rebuilding entire systems are not bad things in my book. In any case saying that this needs to be dealt with solely at the OS layer does not make sense to me.

Having said that, is is nice to be able to fully update an OS, including kernel, whilst running, but ultimately it is just a matter of abstraction levels and marketing.

Please note that some security patches can be installed using hotpatching. Here, have some sample code:

https://www.codeproject.com/Articles/1043089/HotPatching-VER...

The executable needs to be compiled with support for hotpatching, and this doesn't address all possible exploit vectors.

Reply on news.ycombinator.com