Fedora 24 Users: Don't Run "DNF Update" From The Desktop

[danieru]

He means running with any package manager on any distribution will likely have similar bug on specific hardware. I have recently reproduced the issue on a hybrid graphics card powered laptop to trigger the crash while normal hardware are unaffected.

Lies, I would have had experienced at least once or heard about it, if it was true with any package manager.

[Zan Lynx]

3. It's *never* a good idea to run a traditional package-based update (whether deb or rpm) from within a graphical desktop, and we've *always* advised against doing that. It's a fundamentally unsafe operation. If *anything* happens to cause either the terminal app, the desktop, or X itself to crash at any point during the update, the update process will *inevitably* also die, leaving the update half-completed and your system most likely inconsistent.

If this is the main problem with running from a desktop environment then it seems trivial to solve. Have DNF ignore SIGHUP and SIGPIPE and just keep doing its job when the terminal goes away. Add that new systemctl call to avoid session kill too.

Then the problem is limited to actual power loss.

[pal666]

I would have instructed the programmers to either: give me a "fix"; deny DNF from working via the desktop ("a workaround"); or, delayed the release of the product rather than introduce a flaw (call it a "feature" if you wish) that might damage the reputation of the product.

i'm glad we are living not in your world. there is nothing wrong with running dnf from desktop, if you crash console with dnf, result will be the same. but smart people run terminals under tmux and desktop crashes do not affect them, because everything should survive desktop crash, not only dnf. (so better workaround is to use tmux, not vt)

[pal666]

Ahm since when is that a problem? Did that for years (updating running software)

i guess sometimes stars align badly. not a big deal though, duplicate packages could be easily removed by anyone who was able to run dnf in the first place

[pal666]

I don't know what you mean, I've always updated Kernel, running Firefox, running Desktop Enviroment, running GTK, everything. on my distro without any issue.
But Fedora seems to often hit this kind of bugs.

or maybe fedora just has more users than your distro

[pal666]

I never liked DNF. It requires a huge amount of metadata from repositories. If you are on a not-so-good internet connection, dnf takes a long while. Heck even APT now does parallel downloads and doesnt download 50MB+ of metadata from its default repos.

dnf does parallel downloads and it does not have 50m of metadata in default repos. dnf just updates cache automatically after short timeout, while apt has special command to do that, but you could run dnf --cacheonly

[pal666]

Have DNF ignore SIGHUP

http://man7.org/linux/man-pages/man1/nohup.1.html

[danieru]

or maybe fedora just has more users than your distro

I use 3 distros in total, one of them being ubuntu, so the user number is out of question

[finalzone]

Lies, I would have had experienced at least once or heard about it, if it was true with any package manager.

How can be a lie after being explained the source of the issues i.e. X and systemd-udev-trigger as highlighted on

https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/902361-fedora-24-users-don-t-run-dnf-update-from-the-desktop?p=902416#post902416

showing using any package manager (whether it is apt-get, pacman, etc...) for updating on a terminal within a graphical desktop will result the same effect?

[AdamW]

How can be a lie after being explained the source of the issues i.e. X and systemd-udev-trigger as highlighted on

https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/902361-fedora-24-users-don-t-run-dnf-update-from-the-desktop?p=902416#post902416

showing using any package manager (whether it is apt-get, pacman, etc...) for updating on a terminal within a graphical desktop will result the same effect?

Neither of you is really wrong. All traditional package management tools are basically subject to this type of issue. This specific bug is not exactly particular to Fedora, but you equally can't say it would happen on any other distro; the key point is that Fedora's systemd-udev package includes a restart of systemd-udev-trigger.service in its scripts. I suspect that restarting systemd-udev-trigger on the affected hardware on pretty much any distro would trigger the bug (though I haven't actually checked this, it's just a supposition), but the restart of the service in the package scripts is basically a package maintainer choice, and other distros may not do that. Indeed, our short-term fix for the bug is simply not restarting the service in the package scripts any more.