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. poc _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
