GNOME Bugzilla – Bug 658671
Fail whale dialog causes data loss
Last modified: 2021-06-14 18:23:17 UTC
Gnome shell can die for any number of reasons. When it dies, usually other programs keep working, even if they can be hard to interact with. Unfortunately, when gnome-shell dies, gnome-session insists on killing the session the rest of the way -- it covers the entire screen with "Oh no! Something has gone wrong." The only option is to log out, which almost guarantees data loss. I'd like a second button like "Buzz off" (obviously a better string would be needed) that just dismisses the fail whale dialog. This probably goes against some GNOME 3 user interface guideline or other, though. A better solution might be a "Try to save my work" button that (after giving some instructions) dismisses the dialog for awhile and brings it back after, say, 60 seconds. That way the user can try to save his or her work. (I am typing this bug report right now from a session that would be perfectly functional if one of my monitors wasn't covered in the fail whale dialog. I got to this state by typing metacity --replace, but killall gnome-shell would likely have caused similar results. The message that the "system can't recover" is a flat-out lie. The system *is already working*, except that gnome-session hasn't figured it out.) My apologies if the behavior in GNOME 3.1 / 3.2 is already better. I'm running Fedora 15, and I don't want to build a whole new GNOME version just to test this.
FWIW, typing 'gnome-shell --replace' brought my session back to full GNOME 3 functionality, but that fail whale dialog is still there. Surely gnome-session could at least be smart enough to try the --replace WM option.
*** Bug 660335 has been marked as a duplicate of this bug. ***
gnome-shell just exploded in the middle of a large update of Fedora. Fail whale opens. I see the hard drive light still flashing while the update finishes. The fail whale is helpfully suggesting that I "Log Out" (as my absolute only option). That doesn't seem like such a great idea right now... This could lead to someone _seriously_ damaging their system.
gnome-shell had died during update,and I was presented with whale fail dialog, while irc/email/documents were being worked upon. Not very helpful, and lead to data loss. from ./gnome-session/gsm-fail-whale-dialog.c 356 gtk_window_stick (GTK_WINDOW (fail_dialog)); 357 gtk_window_set_position (GTK_WINDOW (fail_dialog), GTK_WIN_POS_CENTER_ALWAYS); 358 /* only works if there is a window manager which is unlikely */ 359 gtk_window_fullscreen (GTK_WINDOW (fail_dialog)); <--- could this please be removed
On my system I get the fail whale when g-s-d segfaults (and can't be restarted?). So I actually have a working window manager, my apps just doesn't have a pretty theme. That's seriously bad behaviour to just jettison the session...
If you get the fail whale when g-s-d dies and actually does restart then that is a separate bug. If g-s-d dies and can't be restarted your session is hosed. g-s-d does a lot more than set your theme. Data loss is never acceptable in an application and the answer for that is for an application to never lose your data. It must be robust against application crashes just as it is needs to be robust again session and system crashes or power loss. As for updates, they should not be performed during a running session - ever. The current update mechanisms are completely broken in this respect. That needs to change. The only concrete thing I think we might be able to take away from this bug is that perhaps we can emit a signal over dbus or x to signal apps to panic save and die.
In an ideal world, logging out and logging back in would always be a lossless operation. In that case, the fail whale dialog would be annoying but harmless. Since we're not in that ideal world, and since gnome doesn't control things like Qt apps and the distro's updater, this is IMO still a real problem. (A dbus or x signal will never do anything intelligent to cli programs, and cli programs in terminals aren't going away.)
I know that g-s-d does more than setting the theme, but it dying does not prevent me from saving my work, telling people I'm chatting with that I need to disappear for a moment etc, and logging out and in again manually. (I'd probably prefer to stay logged in and figure out why it can't be restarted.) Bug or not, the fact that that the fail whale dialog turns an annoyance (g-s-d dying) into a situation that's only marginally better than restarting X seems like good sign that it is plain dangerous. Could we at least have an option to logging out, a "It broke, but please let me keep both pieces." button added to the fail dialog?
as an aside, you can hit 'alt-spacebar' and minimize the fail whale, or alt-f4 and close it.
(In reply to comment #6) > Data loss is never acceptable in an application and the answer for that is for > an application to never lose your data. It must be robust against application > crashes just as it is needs to be robust again session and system crashes or > power loss. I strongly disagree. I work a lot with vi over ssh. When the connections is destroyed here it is a *big* loss normally. Yes, an application should be robust against that, but since the failing whale has the tendency to show up a bit too often, it would be a reasonable decision to make him less occupying. > As for updates, they should not be performed during a running session - ever. > The current update mechanisms are completely broken in this respect. That needs > to change. Again wrong. Even if libs are overwritten by new ones, the ones that are loaded and used are still kept alive and present. Of course, if you continue to start programs and interact a lot, you might run into problems, but hell, we are talking about Unix here, have you ported g-shell to Windows? > The only concrete thing I think we might be able to take away from this bug is > that perhaps we can emit a signal over dbus or x to signal apps to panic save > and die. No. There should be an options to postpone the forced logout. There is NO NO NO reason to be forcibly logged out if I still can fire up a terminal and type in a shell!?!?!? A signal to ssh will not help the screen and vim and mutt behind it. Thanks Norbert
*** Bug 672632 has been marked as a duplicate of this bug. ***
This behaviour is atrocious! I just lost an hour of work due to being forcibly logged off without having a chance to save my data.
FWIW, the current way to recover seems to be: 1. Press Alt-F4. If it works, you're good to go. 2. Ctrl-Alt-F2, log in, and run DISPLAY=:0.0 gnome-shell --replace 3. Ctrl-Alt-F1 (or F7, depending on distro, or maybe even F8 or F9). Try Alt-F4 again. 4. Go back and log out your vt session. This bug can be triggered even when nothing whatsoever is wrong if the package manager restarts gnome-shell a couple times in a row.
Hi Andy, (In reply to comment #13) > > This bug can be triggered even when nothing whatsoever is wrong if the package > manager restarts gnome-shell a couple times in a row. I'm assuming here you were hit by the combination of two bugs: 1) Fedora's NetworkManager %post restarting NM (clearly broken) 2) A bug in gnome-shell that caused it to crash if NM was restarted Both are now fixed.
How about sending SIGTERM to all processes attached to the current gnome-session? That would at least prevent some data loss (e.g. in firefox).
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version of gnome-session, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-session/-/issues/ Thank you for your understanding and your help.