On Fri, 2017-09-08 at 10:26 -0700, Rick Stevens wrote: > IIRC, on process startup ld checks to see if the desired _shared_ > library is already present in RAM and only loads it from disk if no copy > already exists in memory (that's the whole point of shared > libraries--only one copy of the _code_ section is needed). So even if a > library was updated, the new version won't be used unless _all_ > processes currently using the old version shut down and a new process is > launched that needs that library. The only way to ensure you're using > the latest and greatest version of any given library is to do a reboot > to kill all the existing processes. Whether to run a new kernel at that > reboot is up to you. Yes and no. AFAIK if some process is using libfoo.so.3.1 and an update installs libfoo.so.3.2, subsequent processes will use libfoo.so.3.2 so there will be two versions of the library in memory because strictly speaking they are different binaries. That's why you want to kill (or equivalently re-exec) processes using libfoo.so.3.1, which is what tracer is telling you to do. However not doing it will not block use of the new version, it will just be more expensive. > Now, should the package manager of choice alert you to potential > changes? Unless the update to the library is security-related or > prevents some potential catastrophic meltdown, I see no particular > reason to. Others feel differently and may install the tracer plugin > to be alerted automatically (at the cost of a slower update cycle) or > they run "dnf needs-restarting" should they feel like it. The choice is > theirs. > > I don't run automatic updates. I run them interactively and look at > what's being updated. That way I can determine what to do. It's the "determining what to do" that we're talking about. That's the hard part. poc _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
