On 03/25/2015 03:39 PM, Martin Cigorraga wrote:
Hello Richards,
Quite interesting to actually talk to someone who actually has his hands dirty and can talk about this issue :)
I remember reading a Lennart's post on his blog about a future when packages will be installing in their own spaces and all of this managed by systemd.
That exists in two forms: docker and CoreOS. Both really designed for virtualization stuff (like AWS). Indeed, setting up CoreOS on real hardware is a right pain in the arse.
Now my question (may be an innocent one, I'm full aware of that) is: Why a core technology piece like the kernel can be patched in place (and I hope we see this awesome feature implemented in the neigh time) but on the contrary there is so much trouble when trying to upgrade other 'simpler' (if you allow me) pieces of software? Damn, I believe that even systemd is designed in a way it can be hot-upgraded too without the need of rebooting the system...
Thanks for your time.
I can't say exactly what the criteria are for Linux (a lot of my experience goes back to other OSes), but I'll take a whack at it.
In my experience, it's very dangerous to try to patch the _running_ kernel. One could snapshot it into another chunk of RAM, patch that copy, then switch control to it by poking address registers on the CPU. I'd say it's very involved and still prone to problems (and note I said patching, not installing a new kernel).
Updating software that isn't running is trivial. Updating software that _is_ running also is trivial as long as you keep in mind that the running program is the program BEFORE the update. It's already loaded into RAM, pulled in the libraries it wants loaded along with their private data areas (BSS and data segments). You'd need to stop the currently running program and reload the image from disk (re-run) to get the new version.
If you update libraries a running program uses, it won't get the new libraries until it is restarted since it's already got a copy. In fact, I think any program that starts and wants that updated library will get the old version as it's already in memory.
Some programs demand that they be restarted when updated (actually, that's usually part of the package manager's "postinstall" stuff), typically because the patches or whatever fix a really bad bug or security issue. Some maintainers are a bit overly zealous in this area and insist on restarts even for minor fixes.
There are cases where even a library update might mandate a reboot. For example, let's say there's a big security fix in glibc. I can easily see that insisting on a reboot since pretty much EVERYTHING uses glibc.
To ensure everything is using the new library, you really would need a reboot. If you're truly paranoid, a full-tilt hard (power-off, wait, power-on) reboot to make sure RAM is clean of any potential evil code still lurking around.
"Just because I'm paranoid doesn't mean they AREN'T out to get me!" ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - Trying to make digital files uncopyable is like trying to make - - water not wet. -- Bruce Schneier - ----------------------------------------------------------------------