[SOLVED] Close or Disable "Oh no! Something has gone wrong" screen without log out?

Desktop
1

44.9/X11

I find this window to be more of an annoyance and hindrance than helpful. I’m not clear what triggers it, but it’s no where near as catastrophic as I’m nearly forced to believe. It may happen during intense swapping going on that causes oom-killer to kill something? Not sure as I haven’t had much time, and it’s nothing serious.

By using Alt+Spacebar I can remove the window from being always on top and always on visible workspace, and then move it right until it’s not on any of my workspaces, then continue what i was doing… sometimes for weeks longer before I decide to reboot… more like nothing has gone wrong but if this window had its way it would ruin my browser session or any other unsaved data i might’ve had open.

Unfortunately, as soon as I close this window it kills my session. If there is a way to close it without causing that, or just disable it completely, or switch to some less obnoxious warning/error notification, I’d appreciate knowing. Thanks

2 Likes
2

I found the source of the “Oh no!” overlay screen is the userland gnome-session-failed service. I took control over my session back by disabling and masking it:

systemctl --user disable gnome-session-failed.service
systemctl --user mask gnome-session-failed.service

Now, try as it may, it’s been unable to interfere with my session and my work:

Feb 26 06:29:10 throne systemd[1581069]: org.gnome.Shell@x11.service: Failed to enqueue OnFailure=gnome-session-failed.target job, ignoring: Unit gnome-session-failed.service is masked.
Mar 01 01:36:53 throne systemd[1581069]: org.gnome.Shell@x11.service: Failed to enqueue OnFailure=gnome-session-failed.target job, ignoring: Unit gnome-session-failed.service is masked.
Mar 06 16:14:18 throne systemd[1581069]: org.gnome.Shell@x11.service: Failed to enqueue OnFailure=gnome-session-failed.target job, ignoring: Unit gnome-session-failed.service is masked.
Mar 09 22:44:19 throne systemd[1581069]: org.gnome.Shell@x11.service: Failed to enqueue OnFailure=gnome-session-failed.target job, ignoring: Unit gnome-session-failed.service is masked.
Mar 11 12:05:41 throne systemd[1581069]: org.gnome.Shell@x11.service: Failed to enqueue OnFailure=gnome-session-failed.target job, ignoring: Unit gnome-session-failed.service is masked.
Mar 17 04:02:48 throne systemd[1581069]: org.gnome.Shell@x11.service: Failed to enqueue OnFailure=gnome-session-failed.target job, ignoring: Unit gnome-session-failed.service is masked.
Mar 20 09:23:47 throne systemd[1581069]: org.gnome.Shell@x11.service: Failed to enqueue OnFailure=gnome-session-failed.target job, ignoring: Unit gnome-session-failed.service is masked.
Mar 23 17:37:09 throne systemd[1581069]: org.gnome.Shell@x11.service: Failed to enqueue OnFailure=gnome-session-failed.target job, ignoring: Unit gnome-session-failed.service is masked.
Mar 28 21:51:17 throne systemd[1581069]: org.gnome.Shell@x11.service: Failed to enqueue OnFailure=gnome-session-failed.target job, ignoring: Unit gnome-session-failed.service is masked.
Mar 30 18:29:39 throne systemd[1581069]: org.gnome.Shell@x11.service: Failed to enqueue OnFailure=gnome-session-failed.target job, ignoring: Unit gnome-session-failed.service is masked.
Apr 02 01:34:53 throne systemd[1581069]: org.gnome.Shell@x11.service: Failed to enqueue OnFailure=gnome-session-failed.target job, ignoring: Unit gnome-session-failed.service is masked.
Apr 04 19:36:36 throne systemd[1581069]: org.gnome.Shell@x11.service: Failed to enqueue OnFailure=gnome-session-failed.target job, ignoring: Unit gnome-session-failed.service is masked.

:smiling_imp:

I’m not yet clear on what triggers it, but it’s clearly got a hair trigger. I’ve not noticed any negative side effects from this, either. All apps, including Gnome apps and integrations, and all my extensions continue working as expected. This has increased my session uptime by almost 20-fold so far,

$ ps -o etime= -p $(pidof gdm-x-session)
38-07:15:32

and on-going, increasing to infinity.

This has worked wonders on my productivity and my stress levels!@

⠀⢀⡀⣴⡆⣰⣾⡷⠀╭────────────╼
⢶⠘⠃⣈⣀⣙⠋⠀⠀│ GNOME 47.3
⢀⣴⣿⣿⣿⣿⠇⠀⠀│ X11
⠘⣿⣿⡟⠋⣀⡀⠀⠀│ Debian trixie/sid
⠀⠈⠻⢷⣶⠿⠃⠀⠀╰────────────────────╼
3

I’m not yet clear on what triggers it,

journalctl -f shows runtime logs (warnings / errors etc) for the entire system.

You can check it for clues when the issue happens.

4

Yes sir, thank you, I do typically have journalctl -f running in a ddterm window but I still couldn’t make sense of anything at the time. I am constantly learning, though, so it might be worth a revisit, especially if it can help improve the project! I’ll see if I can find the full context of past occurrences and go from there…

5

I just happened to have this problem. The UX is not great.

the good

Gnome is effing awesome. It has an amazing desktop environment UX overall.

the bad

But out of all UX I have seen in the whole Linux desktop environment world, this “window of doom” is arguably the thing with the worst UX out of everything.

It would be nice if Gnome would allow closing the window, and make logging out be a recommendation, not a requirement.

2 Likes
8

Right? What a concept. Like: turn the window into some sort of red indicator icon or something instead of forcing a logout.

The messaging must be updated too. The spiel about not being able to recover is a farce since we can recover by simply using Alt+Space to open the window’s menu and remove it from “always on top” and “always on visible workspace”.

In the beforetimes, when I would just move the window to a far away workspace, it would still suddenly terminate the session and all processes the next time whatever triggers it happens again (which could be days later), which causes the window to be closed thus triggering a forced logout and data loss. This was still plenty of time to save all my work and log out manually…

9

Please open an issue against the respective project in GitLab.

10

is the project gnome-shell or?

11

The screen is shown by gnome-session: GNOME / gnome-session · GitLab

1 Like
12

There are already issues opened about it :slight_smile: no need to open more (and please don’t leave “me too” comments, just thumbs up the issue)

Good news is that the dialog only exists on X11 and will stop existing soon. So, I’m probably not going to spend any time or energy on it. The bug will be closed when the dialog is completely stripped out of GNOME

1 Like
13