On 09/08/2017 08:25 AM, Patrick O'Callaghan wrote: > On Fri, 2017-09-08 at 23:14 +0800, Ed Greshko wrote: >>> That whole testing of services and whether their restart/reload is >>> needed, then actually restarting them is something the dnf installer >>> might be able to do by itself: Inform the user - maybe at the end of or >>> during an upgrade - which services need a restart: dnf: "Shall we >>> restart foo now: Yes or No, and if No: here's how you can do it manually >>> ...." >>> Or if a reboot is required: tell the users ... That whole procedure >>> looks actually like a no-brainer ... >>> >>> What did I miss? ... >> >> IMHO, it should be changed from "needs" to "should". It is often the case that >> processes which are already running will continue to run just fine even though they >> "should" be restarted to make use of the updated libraries. >> >> It isn't as cut and dry as you may think. It probably isn't a good idea to restart >> some processes after an update as a user may be accessing the process and restarting >> it in the middle may make for a bad user experience. A connection to a socket may be >> broken, for example. > > Yes, the situation can be complex and I wouldn't advocate dnf just > restarting stuff without asking first. I wasn't trying to understate > the difficulty. Nevertheless, key services should be restartable by the > user without having to poke around in documentation, which is often > incomplete or even non-existent. Core services descend from systemd, > but in some cases there is no corresponding target or unit file because > the execution was down via something else. If tracer is smart enough to > know what processes are using obsolete libraries, I presume it could > be made smart enough to read the journal and trace how the process was > originally run, but of course this is mere speculation. 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. 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. Being the oddball I am, I do periodic reboots (generally the first thing every Monday morning) so I'm running the newest kernel and using the latest libraries. But (as everyone familiar with this list knows) I'm simply cranky, obnoxious and "weird". ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@xxxxxxxxxxxxxx - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - If Windows isn't a virus, then it sure as hell is a carrier! - ---------------------------------------------------------------------- _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
