On Wed, 2016-10-05 at 02:59 +0000, Andrew Toskin wrote: > This is the first I've heard of any recommendation like this. If > running `dnf upgrade` from a graphical console is such a big and > well-known risk, then why isn't it mentioned in the dnf > documentation? I've posted about this on the dnf Bugzilla. > > https://bugzilla.redhat.com/show_bug.cgi?id=1381785 > > I'm having a hard time finding anything about this in the Fedora Wiki > either. If you could recommend any particular reading that could > explain this some more, I'd appreciate it. Hmm, well, there isn't necessarily an awful lot of explicit documentation of this, I guess. I dunno what's in the user guides these days. When I said we don't recommend updating from a desktop console, I guess I was thinking mostly of mailing list discussion, IRC, forums etc. rather than formal documentation. I don't think there really *is* any How To Update Your System guide, like we have an Upgrading guide. > I tried to read every message in this email thread, but I'm still not > clear: It seems the bug that inspired the original post is based on > certain graphics hardware, but you still say it's best not to run > system updates from a graphical session at all anyway. Is most of the > risk related specifically to X and the large software stack that runs > on it, or is it simply a problem of numbers, where more running > processes means more things could crash while dnf installs updates? I'd say broadly speaking both, but the most disruptive and potentially catastrophic effect is when the update process itself crashes or is killed. Because of how RPM transactions work, this generally leaves you with RPM convinced you have two copies of a bunch of packages installed, and cleaning that up is kind of tedious. The more processes are running underneath the dnf process, the more likely the dnf process is to get knocked out by something else. (I don't know if dnf could sensibly be changed to mitigate this issue; it's really not my focus. I just want to try and help real users deal with the software as it currently exists.) The effect where the update causes running processes to misbehave is usually less of a big deal and more just a case of 'eh, restart it or reboot, no big deal'. Note I didn't write about using tmux or screen for two reasons: 1) I'm not sure exactly how safe that is from the systemd KillUserProcesses change 2) I didn't want to talk about somewhat-advanced topics, I wanted to keep it simple but if you do actually know what you're doing with tmux/screen, and someone can clear up the KillUserProcesses thing (or you just make sure the server process is launched outside of the user session, I guess), then I think running an update from a tmux/screen session running on a terminal in a desktop should be nearly as safe as doing it in a VT. > Fedora Workstation users are apparently recommended to use GNOME > Software's reboot/update feature; what's the recommended way to > update all packages on instances of Fedora Server or Fedora Cloud? I'm not sure we actually *have* an official recommendation. My take would be that it depends on your risk tolerance. Obviously on a typical Server / Cloud install you're not going to be running the update in a graphical desktop session, so that avoids a lot of the risk right there. It's still technically a bit safer to use the pkcon-driven offline update process than just to update in a VT or with dnf- automatic or a cron job or something, but it's a much smaller difference, I'd say. The one thing I absolutely would advise against: don't do an update over ssh! Unless you use screen or tmux, of course. But just sshing in and running an update is a great way to potentially hit trouble. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
