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@xxxxxxxxxxxxxx -
- AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 -
- -
- Trying to make digital files uncopyable is like trying to make -
- water not wet. -- Bruce Schneier -
----------------------------------------------------------------------
--
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
