Don't update from within a Desktop Environment?

[PseudoKrazy]

Was reading this( https://lwn.net/Articles/702629/ ) article by a Fedora dev today. As it turns out, running "dnf update" from within a DE is not officially supported, as sometimes things can break.

Is this also the case with emerge? Should I not be running my emerge worlds from within a DE or WM, or does it not matter?

[Ant P.]

Fedora's updater is just really shitty. Killing processes from an update script makes them stop running, who'd have thought‽

It's safe here - Gentoo neither starts services behind your back nor murders them. As long as you don't rely on equally brain-damaged software (like KDE's screen locker)

[John R. Graham]

Here's the practical answer. Something can break, but it won't be the emerge, nor the built software. At most, the desktop will become a little flaky and need to be restarted. Here's why. In a perfect world, all shared libraries that could be used by a desktop environment would be identified at startup time and would be opened. That would guarantee that the running DE to have its own private (stable, unmodified) copy of all of the shared libraries that are being updated, even as they are being replaced by the running emerge. Unfortunately the world isn't perfect—and desktop environments are complicated beasts. It's unrealistic to expect all shared libraries to be identified like that. So, although much of the time, nothing will break, sometimes the DE will become flaky. On a single user machine, I wouldn't sweat it.

- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters.

[daveg]

I update from within a DE, and have odd behavior a time or two. My advice: Run the updates in a tmux or screen session so they are not disrupted by anything happening in the UI. Worst case, you jump to a text console, kill X, and reattach to the tmux/screen session.

[Hu]

I concur with daveg. The danger with the Fedora update process is that it (necessarily) makes non-atomic changes to the system, so an ill-timed crash can break things. The problem is that, if you run dnf update from an xterm (or GNOME terminal, or Konsole, or ...), then any error that kills the xterm will kill the dnf process. That means you need both xterm and the X server not to die. If you instead run the updater under tmux, then you only need tmux not to die. Tmux is simpler than either of the other two, and so is more likely to meet the conditions that JRG described for a safe run. All these dangers apply equally to all updaters, whether Fedora, Ubuntu, or Gentoo.

The only safe path would be for the kernel to provide a transactional filesystem, so that the updater could create its target filesystem image in private, where no other process can see or be affected by the queued updates. The updater then makes a single syscall that atomically makes all those changes visible to other processes. I am not aware of any way to do this with a mainline kernel, nor any popular patches that provide such a feature. Such a feature is likely quite complex to implement.

[Roman_Gruber]

I hardly remember having issues updating my box from a desctop environment.

I did for a while run portage from a tty and did tail -f /var/log/emerge.log or what it is called to see what is currently done by portage

--

The only issue with portage is that updating nvidia binary driver ruins Direct rendering. That's nvidia fault. And i am too lazy to hardmask newer packages as I did in the past.

--

Well binary updaters are general not that awesome. I had issues with arch linux killing itself and linux mint ruining hole bootloader... Stupid binary distros. WEll windows does the same, when you look at the nerd news ... with failed updates ... and firmware with windows 10.
I had several binary installations as backup distro over the years and they killed all themself during the update process. It seems reinstall is the way, and they never tested updates, and keep update sources. And binary distros are unfixable. I fixed several screwed up gentoo installtions but with binary nope, source does not exists, dependency hell ...

[miket]

This is one reason I like using a build host. Just as updating while running a DE might put you in the situation where a newly emerged library or executable that does not replace a running program might cause problems if the DE tries to start it, your whole system may well go into an inconsistent state during the process of a long emerge. If a build goes off the rails (as sometimes happens) and you have to do some song and dance to work around the problem, your system is less than fully usable until you get the situation cleared up. If at this point you become so unlucky that you have to restart your system, you might find things not coming up properly.

By doing the big work of the builds in a chroot somewhere else, ebuilds that break are much less problematic. You can work out the problems and still have use of a fully functional main system. By the time you apply the updates to your main system, they all run pretty quickly and have much less chance of running into install-time problems.

Edit to add note to Roman_Gruber: by using the build host, you have your own private binary distro. If you have problems, you can work them out--and still retain that one advantage of binary distribution, the fast application of updates.

[augustin]

[Naib]

Take big desktop environments... GNOME and KDE. Now take a major version bump 3.x => 4.x. These two desktops also align MAJOR version bumps to a toolkit major version bump (not always but generally yes.)

So you are in KDE using Qt4 and you have an update (emerge, apt-get, yum, <insert poison> ) and what you are using is being updated. While kTerminal runtime will be in RAM and inodes for the library in-use will be preserved ... at some point you may launch an application whose complete run-time has not been installed and thus unexpected things can happen; usually the application does not launch until its runtimes are in alignment.

Now consider a binary distribution where they will replace almost everything, the chances of some aspect of the DE reloading but part of its runtime dependencies are not in alignment is larger.

I have been running Gentoo for over a decade and I have never ran into an update within a desktop environment "breaking things" partially because it is a rolling release, if you update regularly it is a few packages here and there. I also use Openbox so its a light DE and not a monolithic architecture.
Now an Ubuntu box I manage at work... that's different. Unity went odd and essentially crashed X during an update... took a bit to convince apt-get to continue via a terminal..
_________________
#define HelloWorld int
#define Int main()
#define Return printf
#define Print return
#include <stdio>
HelloWorld Int {
Return("Hello, world!\n");
Print 0;

[devilheart]

[augustin]

[devilheart]

[Zucca]

I run emerge operations inside tmux just if something happens to X for the terminal program, emerge will continue running and know nothing about the crashed programs.
So yes. I run package installs and updates most of the time from GUI side.
_________________
..: Zucca :..

[tld]

[Hu]

I have seen the xscreensaver problem with some PAM updates. XScreensaver needs to load and use PAM to verify your password, but does not keep enough of it loaded for that to work if you update PAM in certain ways. If you checked your logs after such a failure, you would likely see warnings about failing to load PAM files.

[asturm]

So the xscreensaver problem is actually the same as the kscreenlocker problem. With the difference that kscreenlocker has the security issue covered that it may crash, so it's not as easy to gain access again.

[tld]

[Logicien]

It look to be a good idea to use the --resume option of Emerge when using it within a desktop environment even all the time during an upgrade, in case off ... an error.

[Hu]

No, --resume is meant to be used after you run emerge and it fails (whether due to system crash, out of space, out of memory, or a bug in the ebuild/upstream code). Per the documentation that you quoted inline, it is a shorthand for specifying the arguments of the last failed run (with a bit of cleverness to avoid redoing work that finished successfully). It is not a way to force emerge to gracefully handle untimely attempts to kill it, which is the problem discussed here.

[jonathan183]

I always do admin stuff in a tty rather than gui, this means in Gentoo I always use emerge in a tty. My admin user is able to use sudo and use a tty for almost everything (gparted being one exception where I use a gui as the admin user).
Regular user can use the gui but are unable to run emerge in anything other than read only mode.

I take a similar approach for other distros where cli package updates are supported with the exception of Mint where I think the gui update manager is the preferred option.

The only time I would think of using emerge in xterm would be if I wanted to capture output to copy and paste when asking for help, but I'd probably redirect emerge output and error outputs to a file and cut and paste from them ... something like

[sligo]

The only thing that i run into from time to time is a broken X because i've updated my kernel and forgot about Nvidia drivers. Other then that, i never had trouble running emerge updates from inside XFCE terminal.

[Logicien]

[Hu]

[eccerr0r]

I think if you're brave you can emerge/update while in a DE, but as suggested many times, the rug will be pulled from beneath you and things can and will break. Hopefully that terminal emulator won't need to pull more data from the disk because it might have disappeared (DON'T CHANGE FONTS!) Really doesn't matter what OS, many will require a reboot or at least a GUI restart to fix things.

Worst things that I've encountered during emerges that have basically killed the DE:
- xscreensaver/pam/shadow/gnome-screensaver - can't unlock screen anymore.
- xfce4-panel and other DE main panels - file locations changed and no more items on the panel.
- library versions change mid flight and no longer exist, can't open new terminals or other programs
- half baked / killed emerges that have inconsistent DE revisions on disk

There is good reason why M$ wants reboots every update, and now we're seeing strange occurrences in our DEs... Fortunately for M$ most of the changes they tried hard to be backwards compatible so half-bake problems don't happen as often.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

[Logicien]

You are right Hu about the --resume option. It must only be provided after an error without any new atom. If you really worry about Emerge being kill by a Gentoo upgrade you can do it in a chroot if you trust the host. Than you can have the Gui of the host.