Must Start gnome-session Manually for GNOME Software Button "Restart & Install" to Work (Xfce)

Ask Fedora
, ,
1

I have never used GNOME software, but since is the only way to stage package updates for install on reboot, AFAIK, I would like to start using it, now. But, I’m having troubles…

gnome-software let’s me check for system updates and download system updates. But, when I click the “Restart & Install” button, nothing happens, except I get this error in the journal:

Aug 23 12:22:41 wrangler gnome-software[3982]: Calling org.gnome.SessionManager.Reboot failed: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.SessionManager was not provided by any .service files

So, I started gnome-session manually and then the button worked, a reboot occurred and updates were installed.

Does anyone recognize this symptom?

In Xfce, I have “start GNOME services” checked. Is this not enough to have gnome-session started automatically? Is it supposed to be running? Why doesn’t gnome-software start it if it needs it?

1 Like
2

Probably this feature is not designed to work outside of GNOME session:
Name "org.gnome.SessionManager" does not exist (#134) · Issues · GNOME / mutter · GitLab

I think, you can get a more certain answer here:
https://discourse.gnome.org/

2 Likes
3

Me personally, I still find it more transparent and verbose to do my updates with dnf.

I just manually reboot after applying updates – if I see the need to.

You can also simulate gnome-software’s behavior more closely by rebooting before applying updates, doing them in tty and not the graphical session, and rebooting again after doing so – though I’ve never seen a clear indication that’s useful.

4

Closing the session may be helpful in some cases, but rebooting before updates should be redundant.

Actually, rebooting after updates is not mandatory either, but it is usually faster than manually restarting the affected services and applications on a typical desktop/laptop.

See also:

1 Like
5

You might be right.

I wish there was a way to stage “offline” updates with some other tool, like DNF.

1 Like
6

Thanks @vgaetera & @nightromantic.

I’m very familiar with these DNF workflows. But, I recently had a second crash during DNF update that convinced me it is no longer safe to do updates that way, at least while a DE session is active. Apparently, others have been sounding the alarm for a while.

I find this idea antithetical to the UNIX/Linux ethos, but I’ve learned the hard way. The two problems have occurred in the recent past; I never had any trouble before that.

It’s not clear that the DE session is the issue, either. I’m not convinced that just logging out of the DE and going to the virtual console will be enough. I guess I could try it. I worry that it is actually some VM fragmentation or mem leaks, not something with the DE stack, that makes the update process unstable.

I’d like to know more about this. What about the DE can make package updates crash the system?

If it’s not the DE, then rebooting before is important. If it is the DE, then logging out of the DE and restarting services should work. Although, I doubt restarting all necessarily services is easier than just rebooting.

I like the idea of going to runlevel 1 or 3, doing the update, then back to runlevel 5. But, is that any quicker/easier than just rebooting twice? Maybe. I guess I could play around with these workflows.

It’s just that, it’s a great idea to automate this, and gnome-software did it. So, what do I gain by doing all that manually? Well, I can think of two things: I don’t have to use packagekit and it actually works without gnome-session.

7

Of course, it is not, but it should be enough to install the updates and reboot afterwards.
Note, that you should poweroff the VMs beforehand if you use virtualization.

To be clear, every time after update you should run:

sudo dnf needs-restarting

And restart the listed services and apps or reboot the system.

8

@pdestefa, I’d like to add to this thread a bit – as you’ve brought up a rather major issue. I’ve did some more research since we’ve discussed it and asked some people for advice.

Regarding updates with dnf.

As you’ve pointed out, it’s not recommended to run dnf upgrade from terminal emulator from graphical DE. Main reason (as stated in Adam Williamson’s letter from the link you’ve posted) is this: if graphical session will restart or crash during update – as sometimes happens – then dnf upgrade process – being the child of the graphical session – will be closed as well, and that can leave system in unclean/unreliable state with rpm/dnf database damaged.

To avoid this it’s sufficient to run dnf upgrade not from a graphical DE but from a tty. In such a case graphical session closing or crashing in the process will not affect dnf in any way.

To minimize non-dnf related possible issues with graphical session restarting/crashing you can exit from you graphical session before running upgrade – as we’ve discussed above.

In fact, this is exactly the way I’m running upgrades for some time now – without being fully conscious about it. I do it – but I haven’t thought about why exactly I do it this way (through a tty with closed graphical session). Now I do it consciously :wink:

It looks like you don’t really need to switch to runlevel 3 for your updates – though it can help in some edge cases.

One other piece of advice I’ve read and received is this. If you really need to run an dnf upgrade process from under graphical environment – run it inside of screen session. In such a case in graphical session restarts or closes – screen should remain unaffected and running – with dnf upgrade process inside it.

Take note, that tmux will be closed when launched from under graphical session in the case of this session closing – this I’ve verified myself. I haven’t verified screen’s behavior, but was told in no uncertain terms that it differs from tmux in this regard.

But actually just updating from tty with graphical session closed is simpler and cleaner. And should be reliable – barring some possible dnf errors, of course. That’s what I continue to do after our discussion here and my additional research.

1 Like
9

Another method to avoid RPM database corruption:

sudo systemd-run dnf -y upgrade
journalctl -f -u SERVICE_NAME
1 Like
10

Interesting. I’d love to hear more about how this works.

11

Thanks for all the useful information. I have taken to using the virtual console to finishing my upgrades, so I think we are using the same workflow, now.

I’m surprised to hear this about TMUX. I switched to TMUX from Screen a long time ago, but didn’t know this. I don’t understand this because I start my upgrades with dnf --downloadonly in a tmux session, then I logout of X, then switch to VC, then reattach to tmux and run dnf upgrade to “resume” the upgrade before rebooting. I don’t understand the relationship between the X session and TMUX to interpret why what you say can happen would happen. Clearly, TMUX is a descendant of X and GDM, but so is screen. Does it have to do with cgroups? Does screen ignore HUP and TMUX doesn’t? Strange.

In any case, I had a new experience that makes me even more disappointed. My system booted into emergency mode/single, recently and I think the only problem was that it wanted me to do a manual fsck. So, I did that, it wasn’t anything too serious. But, afterward, I decided to do a DNF upgrade since I was already in single mode, and that was one workflow I was considering. Well, even that is not safe. During the DNF upgrade, something tripped systemd, or possibly anaconda, directly, to start GDM. I don’t know what or why because as soon as it started, which I didn’t realize immediately, I lost all access to the console (VC1), and the output from DNF. I waited a bit, as it seemed like dnf was still performing the update, and I think that was right, because, after I rebooted, I checked and it seemed like DNF had installed the rest of the updates; it was about half way through when I lost track of it.

So, WTF? I get the feeling that the process is even more fragile than we can anticipate. The system cannot get any more quiescent than single mode, so, it’s not that the update caused a crash or something failed during the update. But, the update actually tripped some trigger that caused systemd to start more services. So, then someone needs to sit down, figure out what the dependencies are, and make a systemd target with those services so we don’t have to flounder around trying to guess the safest workflow.

I’m looking for the DNF, command-line equivalent of GNOME software off-line updates. package-kit knows how to orchestrate this, obviously. So, why isn’t something like this documented and recommended by RedHat and Fedora maintainers? Just seems like something that is really valuable to have and I don’t understand why, after 20 years, it isn’t a standard thing.

12
13

Interesting idea. Seems like that solves the problem of having your dnf upgrade killed if you start it from X or some other unreliable parent process. It also seems to record the output, so that’s nice. It is better than running dnf upgrade from VC since VC doesn’t have a big buffer, so you cannot use it to review the upgrade process after the fact.

I’m most impressed with this idea in the case my latest problem. If you use system-run to start dnf upgrade from single mode, then I would have been able to see what happened in the journal and I wouldn’t have worried about it having been stopped in the middle.

But, does it do anything to prevent crashes during upgrade or prevent dnf upgrade from inadvertently starting services that aren’t already running. I don’t think so. If dnf upgrade is going to crash your system because you have active X session, which is what experts are claiming, then it doesn’t matter how you run it, you still need to quit X.

Something to think about. I think I will certainly try it.

14

Well, that didn’t work at all.

$ journalctl -f -u run-r1d193315a79444e8934b80f17b3748c9.service
– Logs begin at Sun 2019-06-30 12:54:45 PDT. –
Oct 20 13:44:41 ~ dnf[526083]: Transaction Summary
Oct 20 13:44:41 ~ dnf[526083]: ================================================================================
Oct 20 13:44:41 ~ dnf[526083]: Install 6 Packages
Oct 20 13:44:41 ~ dnf[526083]: Upgrade 80 Packages
Oct 20 13:44:41 ~ dnf[526083]: Remove 6 Packages
Oct 20 13:44:42 ~ dnf[526083]: Total size: 185 M
Oct 20 13:44:42 ~ dnf[526083]: Downloading Packages:
Oct 20 13:44:43 ~ dnf[526083]: Running transaction check
Oct 20 13:44:45 ~ dnf[526083]: Transaction check succeeded.
Oct 20 13:44:45 ~ dnf[526083]: Running transaction test
Oct 20 13:45:15 ~ dnf[526083]: Transaction test succeeded.
Oct 20 13:45:16 ~ systemd[1]: run-r1d193315a79444e8934b80f17b3748c9.service: Main process exited, code=dumped, status=11/SEGV
Oct 20 13:45:16 ~ systemd[1]: run-r1d193315a79444e8934b80f17b3748c9.service: Failed with result ‘core-dump’.

Why oh why would dnf core? Confusing. Seems to be running on second try. I don’t know what I did differently. Nice, inconsistent behavior.

15

Might be a symptom of a transient hardware failure.
I’d perform a memory test and a disk SMART check.
Also verify the installed packages:

sudo rpm --verify --all
16

:+1:

I actually need to test is more before I’ll make any definite statements.

Edit: I did test it right now, and tmux sessions don’t get killed when I quit from graphical DE. I rememember clearly having this problem some time ago (not with dnf though – with some script I’ve needed to leave running when I logged out) – but I can’t reproduce it now.

Essentially right now tmux behaved as I would expect it to do regardless of environment I’ve started it from and regardless of whether I’ve detached from the session.

Was it dracut emergency mode or something different? As far as I know, when system can’t mount all the partitions from fstab – for example when one of them needs manual fsck – then it drops you into dracut emergency shell, not a single mode.

  1. I think (I don’t know, of course) that the developers feel it’s not needed for dnf if you use it properly. Properly means not from under graphical session, as we’re discussing here.

  2. This feature in Gnome / Gnome Software got quite a lot of criticism from quite a few people. “Arguments” were I don’t like it and It makes updates too Windows-like – I oversimplify it a bit here – intentionally.

You can use also use sudo dnf history list and sudo dnf history info 0 (-1, -2) to see info about all actions performed during last (0) or previous (-1) etc. transaction – or trasaction id from list output to see any transaction available.

Though it’s not 100% the same as seeing the output from upgrade session itself. Also tmux/screen from under VC should help with this.

1 Like
17

Hmm, it was definitely single. I had to enter the root password. I have seen grub emergency when there is problem booting the kernel, and I think I’ve seen dracut emergency mode, once, when there was a problem with the initrd image, but I’ve only seen single for fsck. If it is checking FS integrity, it’s already into init/systemd.

18

I confess that, after upgrading my hardware, my system has been more stable. It is likely there were hardware problems related to my original post.

Regardless, I think we’ve taken this is a very useful but different direction than my original post. So, I think we can call it.

2 Likes
19

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.