Tools to Manage a gnome-session crash

Desktop
1

Manage a gnome-session crash

For some unexpected reasons the gnome session might stop abruptly :slight_smile:

  • System freeze

  • No more power on laptop

  • Suspend and wake up might not be optimal on some laptops with following symptoms:

    Blank inactive screen (but fan and/or keyboard light on)
    No keyboard or mouse response (which prevent logging from another tty)
    No detectable activity from laptop (but is still turned on)

Thus system or laptop needs to be restarted loosing or crashing the gnome session

What are the gnome system tools/infos to help recover from a gnome session at the time of the crash ?

**Active windows**

** Active Applications**
** Opened documents**
** Content of each workplace**
** etc…**

So far I found only some partials bits in;

~/.local/share/gnome-shell/application_state
~/.local/share/recently-used.xbel

but so far I found no CLI tool and no clear resource on how they work and how to parse them

Is the any extensive way to save/store/access (in realtime ?) gnome session informations and then access them after a crash ?

2

Preserving application state over sessions is a [hard] feature that we have been wanting for long. There are various application-specific caveats to this, but my current bet is that we will start seeing this feature once we have defined a standardized API for applications to serialize/store their state. This is a work in progress starting with https://gitlab.gnome.org/GNOME/glib/-/merge_requests/683

1 Like
3

@felipeborges
Thank you for your reply and your time.

I’m a Linux/Open-source enthusiast user but no developper. For it’s potential of freedom, privacy and security, my goal is to help the every day desktop user to be able to switch easily away from closed source OS and Desktop Managers .

Thus even with as a stable environment as Gnome (I use Fedora) a crash workaround would be a big Need to Have until the long term “Preserving application state over sessions” is reached

Maybe addressing partially the issue by getting as a short term start the infos not from each application but from the Window Manager:
-Does the WM (Wayland,XWayland is by defaut on Fedora if I get this point right ) access the infos on which application has window(s) open and on which workplace ?

4

Does the WM access the infos on which application has window(s) open and on which workplace ?

“Access” is a bit misleading here — workspaces are managed by the WM, so this is its own state, not some external state it has to access somehow.

That state is lost with the session though, i.e. it isn’t serialized to disk, mostly because there’s nothing useful that can be done with that information.

There is no (generic) way to request x windows from an app, and the WM has no knowledge about what each window represents (document, file location, set of tabs, …), so there’s no way to restore any state from “app x has n windows on these workspaces”.

5

Thanks for your reply.
I don’t have enough technical background to fully get your answer.

I found those two workarounds working on Wayland:

https://github.com/adrienverge/gnome-magic-window/blob/master/gnome-magic-window
and
https://unix.stackexchange.com/questions/399753/how-to-get-a-list-of-active-windows-when-using-wayland

They seem to rely on gdbus and get_window_actors

And is seems to pretty well show all my active applications, and even currently active firefox tab or current title of Libreoffice Writer open document, mixing ‘class’ and ‘title’ infos

Wouldn’t it be possible to get a daemonized script or a gnome extension to log the results of get_window_actors in such a script every few seconds into a file which could be called back after a crash ?
It might do the job even if crude.

In a similar fashion, after a crash would offer a GUI recovery , like LibreOffice does offer to recover files or Firefox it’s browsing session after a crash

6

That would work for just restarting applications but probably won’t do so well for restoring application state exactly as it was. For Wayland, a KDE developer just did a talk on this at XDC last month: media.ccc.de - Addressing wayland robustness

I haven’t seen if anyone was actively working on this in GTK or gnome-shell though.

7

Is there a command line to get from the Window Manager, specifically Wayland XWayland and X the workplace identification in which a window is open (associated with it’s application for example ) ?

8

Not really, no.

$ gdbus call --session --dest org.gnome.Shell.Introspect \
  --object-path /org/gnome/Shell/Introspect \
  --method org.gnome.Shell.Introspect.GetWindows

gets you a list of open windows with some properties like title and associated app, but not the workspace.

(It also requires setting global.context.unsafe_mode = true in GNOME 41)

You’d need an extension to override the implementation to provide the additional information you want, but at that point it would be better to just write out the restore file from the extension itself.

9

@fmuellner and all the other participants (I’m limited by 2):

Thank you for your feedbacks.

I’m really out of my depth here. (as 'where to put global.context.unsafe_mode = true in the command you’ve just explained)

I do sense that to correctly address this short term solution , it REALLY needs

  • (1) MORE awareness that some users/people like me discuss/like/need this workaround
  • (2) MORE involvement from skilled users/developpers willing to help
  • (3) Project Management to get FIRST a working Script and then a Gnome Extension DESIGNED for the broadest use cases which are EXPRESSED by users and compatible with overall Gnome’s design directions.

Regarding (1) this topic is also mentioned in another topic with more visibility and momentum here: with @fmuellner and @ebassi proposing and sharing useful insights (and as a side note also there.
(And surely there might be other forums outside discourse.gnome.org debating it too…)

Regarding (2) or (3) I have the will to lead this workaround toward a simple yet efficient script/extension solution. But my know-how on coding or which tools to use is much to limited, say the least .

So from this step forward, what should be the next moves to :

  • (1) MORE awareness
  • (2) MORE involvement
  • (3) USER-DESIGNED Project Management
10

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