On 06/15/2016 11:39 AM, Kamil Dudka wrote: > On Wednesday, June 15, 2016 17:29:02 Miroslav Suchý wrote: >> Dne 15.6.2016 v 10:14 Ade napsal(a): >>> Why is this? Well some time ago the behaviour of the tool changed and now >>> the only way to proceed is to click in "Restart and Install" and this is >>> NEVER what I want to do. I never want to reboot my desktop just to apply >>> updates, Id rather apply all the updates and reboot to bring in the new >>> kernel (if there is one) when I have the time >> Imagine two regular updates. >> >> First you update mariadb-server package. %post is smart and it will >> condrestart the mariadb service. However... >> >> Next day you update "pam" package which provides /usr/lib64/libpam.so.0 >> which is used by mariadb service. Unless you restart your computer your >> mariadb server will continue to use old (and maybe insecure) libpam.so. Or >> unless you use dnf-plugins-extras-tracer: >> http://dnf-plugins-extras.readthedocs.io/en/latest/tracer.html > > It is a reason to restart the system (or just the services of interest) > _after_ installing the update, but not before installing the update. The justification for restarting both before and after installation exists and it does make some sense in certain circumstances. Basically, the problem is that any number of things can change in the state of the system while it has been running that are impossible to predict. For example, the system's memory (and swap) could be almost all used up, leading to unpredictable behavior while processing the update and %pre/%post scripts. Also, a user may have manually played around with the mount table, resulting in some directory paths being unmounted or mounted over that the upgrade would write into. By forcing the system to reboot into a limited environment, it puts the system into something much closer to a known state which is less likely to experience an unrecoverable error. (Ever had a runaway log fill up a disk during a dnf update? Not a good thing.) Of course, this comes with its own headaches, since of course if you are using an encrypted drive, you need to enter your password twice: once to start the update and once for the post-update reboot. A while ago I was working on a patch to PackageKit that would skip the second reboot and just `systemd isolate default.target` after the upgrade unless the kernel (or other early boot package like dracut) was updated. I never finished it, but I could try to dig it out and pass it on to someone who is interested in continuing it.
Attachment:
signature.asc
Description: OpenPGP digital signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
