GDM, GNOME Shell, etc. break when there are stale caches

Hi Guix,

Today I again couldn’t log into my workstation after upgrading the

system. I’m using GDM + GNOME Shell.

At first GDM wouldn’t start. I knew what to do: remove /var/lib/gdm,

because some state must have accumulated there.

GDM came up after a reboot, but I still couldn’t log in. Instead I was

thrown back to the login screen without any error message. I looked in

~/.cache/gdm/session.log for information, but it only told me that

gnome-shell was killed. Thanks.

After removing both .local/share and .cache out of the way I could log

in again.

This happens whenever I upgrade the system. This makes the system

rather frustrating to use. I don’t know if booting into an older system

generation would result in the same problem, but my guess is that it

would because both GDM and GNOME Shell appear to be leaving some binary

files behind that cause different versions to crash unceremoneously.

What can we do to make GDM and GNOME Shell more reliable?

--

Ricardo

On Sun, Aug 04, 2019 at 11:00:41PM +0200, Ricardo Wurmus wrote:

For this one can we create a single-shot service that, on reconfigure or

boot, removes this directory and recreates it? In fact, it seems this is

basically what Debian does¹.

This part seems a little harder to automate. /etc/skel is only sourced

when a user is created, so it's hard to make sweeping changes to help

people in this case, if they even want automated help. I'm guessing

making .cache/gdm(?) read-only would create other issues.

Modify the logout scripts to remove a users' .cache file seems extreme.

Some of the other options, such as removing and recreating directories

would address other issues we've had (such as /var/cache/fontconfig).

¹ https://sources.debian.org/src/gdm3/3.30.2-3/debian/gdm3.postinst/#L76

--

Efraim Flashner <efraim@flashner.co.il> אפרים פלשנר

GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351

Confidentiality cannot be guaranteed on emails sent or received unencrypted

Efraim Flashner <efraim@flashner.co.il> writes:

I suggested as much earlier, but it seems like a hack. Is this how

GNOME expects this state directory to be handled? The fact that Debian

does this is reassuring (or not…), but I would very much like to avoid

adding even more hacks.

Does anyone know why this happens at all? What are the cached data?

Can we do without?

In my opinion generating a global /var/cache/fontconfig should be

prevented; removing it seems again like an avoidable hack.

--

Ricardo

Hi Ricardo,

Ricardo Wurmus <rekado@elephly.net> writes:

It's interesting that I've never run into this problem, not even once,

in all my years of running GNOME on Guix systems. Since recently

reverting to mostly using GNOME under X and GDM (whereas for a while I

was mostly launching GNOME manually under Wayland), I've run into some

other problems, e.g. GDM suspending my system automatically, sometimes

immediately after logging out, but I've *never* had to remove my caches.

I wonder if this is related to my use of Btrfs instead of Ext4. Whereas

system crashes cause file system corruptions under Ext4 (usually in the

form of some files being left empty after a crash), I've never seen any

evidence of corruption from crashes under Btrfs.

Mark

Mark H Weaver <mhw@netris.org> writes:

Interesting.

I haven’t had a system crash on this machine. I didn’t use it for a

month, upgraded, rebooted, and then had GDM + GNOME Shell problems.

--

Ricardo

Hello,

Ricardo Wurmus <rekado@elephly.net> writes:

FWIW, I’m having the same good luck as Mark. Other than the upgrade

from 3.24 to 3.28, I’ve never had this kind of trouble with GNOME and

GDM. And even then, IIRC, the issue wasn’t really with the state files

(deleting them just happened to serve as a temporary work-around).

-- Tim

severity 36924 important

quit

retitle 36924 GDM, GNOME Shell, etc. break when there are stale caches

quit

Hello,

now it is my turn to experience a problem in this area. I newly installed a

machine with the graphical installer of Guix 1.0.1 (where I could use xfce

without problem), then I issued a "guix pull" and a "guix system reconfigure".

Now logging into XFCE poses problems, which I can reproduce as follows

(after removing /var/lib/gdm, $HOME/{.config,.cache,.local} once):

- When I remove $HOME/.config/xfce4/xfconf/xfce-perchannel-xml/xfwm4.xml

I can log into XFCE once.

- The second time, various problems may occur: The terminal, which was open

before opens, but does not receive focus so I cannot type, and the windows

decorations for closing it are absent; or the xfce panel is absent.

- Then I remove $HOME/.config/xfce4/xfconf/xfce-perchannel-xml/xfwm4.xml

again, and can log in once more.

And so on.

The following lines in $HOME/.cache/gdm/session.log appear when there is

a problem:

xfwm4: ../mesa-19.1.4/src/mesa/drivers/dri/i965/intel_mipmap_tree.c:1293: intel_miptree_match_image: Zusicherung ￜimage->TexObject->Target == mt->targetￜ nicht erfￜllt.

(nm-applet:8046): nm-applet-WARNING **: 11:23:52.630: GDBus.Error:org.freedesktop.NetworkManager.AgentManager.PermissionDenied: An agent with this ID is already registered for this user.

xfwm4: ../mesa-19.1.4/src/mesa/drivers/dri/i965/intel_mipmap_tree.c:1293: intel_miptree_match_image: Zusicherung ￜimage->TexObject->Target == mt->targetￜ nicht erfￜllt.

(nm-applet:8046): Gdk-CRITICAL **: 11:23:53.035: gdk_window_thaw_toplevel_updates: assertion 'window->update_and_descendants_freeze_count > 0' failed

xfwm4: ../mesa-19.1.4/src/mesa/drivers/dri/i965/intel_mipmap_tree.c:1293: intel_miptree_match_image: Zusicherung ￜimage->TexObject->Target == mt->targetￜ nicht erfￜllt.

(nm-applet:8046): Gdk-CRITICAL **: 11:23:53.357: gdk_window_thaw_toplevel_updates: assertion 'window->update_and_descendants_freeze_count > 0' failed

xfwm4: ../mesa-19.1.4/src/mesa/drivers/dri/i965/intel_mipmap_tree.c:1293: intel_miptree_match_image: Zusicherung ￜimage->TexObject->Target == mt->targetￜ nicht erfￜllt.

(nm-applet:8046): Gdk-CRITICAL **: 11:23:53.441: gdk_window_thaw_toplevel_updates: assertion 'window->update_and_descendants_freeze_count > 0' failed

(xfconfd:7966): xfconfd-CRITICAL **: 11:23:58.040: Name org.xfce.Xfconf lost on the message dbus, exiting.

(Thunar:8030): thunar-WARNING **: 11:23:58.041: Name ￜorg.xfce.FileManagerￜ auf dem Nachrichten-dbus verloren.

(tumblerd:8023): tumblerd-CRITICAL **: 11:23:58.041: Name org.freedesktop.thumbnails.Cache1 lost on the message dbus, exiting.

(Thunar:8030): thunar-WARNING **: 11:23:58.041: Name ￜorg.freedesktop.FileManager1ￜ auf dem Nachrichten-dbus verloren.

(tumblerd:8023): tumblerd-CRITICAL **: 11:23:58.041: Name org.freedesktop.thumbnails.Manager1 lost on the message dbus, exiting.

(tumblerd:8023): tumblerd-CRITICAL **: 11:23:58.041: Name org.freedesktop.thumbnails.Thumbnailer1 lost on the message dbus, exiting.

Sorry for the German, but you also have the translation:

"Zusicherung ... nicht erfï¿œllt" = "assertion ... failed"

"auf dem Nachrichten-dbus verloren" = "lost on the message dbus"

Andreas

Hallo!

Thanks for the report, Andreas!

Andreas Enge <andreas@enge.fr> skribis:

That’s the likely root cause to me (in which case it may be unrelated to

this https://issues.guix.gnu.org/issue/36924, after all.)

I found these bug reports:

https://bugs.freedesktop.org/show_bug.cgi?id=107117

https://bugzilla.redhat.com/show_bug.cgi?id=1678334

In both cases, Xfce and Mesa’s i965 drivers are involved, as is the case

on your machine. The 2nd bug report includes an xfwm4 patch, even.

I wonder if Xfce before the recent updates (so before

8549e0ca6fd68a57253471436de49b88b2d47e64) works better.

Andreas, if you feel like it, could you try:

guix pull --commit=97ce5964fb5d52cf2151fea685e28fa23a98b264

sudo guix system reconfigure …

?

Thanks,

Ludo’.

Hello,

On Thu, Sep 12, 2019 at 01:40:09PM +0200, Ludovic Courtès wrote:

and thanks for the time spent putting me on the good track!

The first one also contains a patch, but it has been integrated into later

mesa releases, in particular the one we are using.

Indeed, the problem disappears with this commit; I can log in and out

and in again with xfce working. So I am cc-ing the author of the commits

updating xfce, maybe they have an answer!

And I will try to look at the patch in the second report you reference

above.

Thanks!

Andreas

Hello,

Andreas Enge <andreas@enge.fr> writes:

It seems some bugs have been introduced in xfwm4 between 4.12 and 4.14.

(All issues previously linked are for >=4.13 wich was the dev version of

4.14).

I found https://forum.xfce.org/viewtopic.php?id=13233which seems

interesting. Please let us know if it changes anything.

I don't know what would be the correct way to deal with the problem in

guix though.

Have a nice day,

L p r n d n

Hello,

after trying to reconfigure with commit 02b6382169192367e97a2d1bc72f8eb3ed38b0dc

of December 9, I am now running into a problem where I cannot log into my xfce

session under gdm any more: According to the first tty, a session is opened

and closed immediately again, and the gdm login screen reappears.

It is not enough to delete /var/lib/gdm, ~/.cache and ~/.local. Could I try

anything else?

Luckily, there is "guix system rollback" to my working configuration of

September, but I am not very comfortable with running such an old system...

Andreas

Hi Andreas,

Andreas Enge <andreas@enge.fr> skribis:

Did you try your config with the same commit in ‘guix system vm’? Does

it reproduce the problem?

If it does not, that means the problem has to do with state, things like

/var/lib/gdm as you mentioned.

Thanks,

Ludo’.

Hi,

This old bug [1] is there since a long time. What is the status?

1: http://issues.guix.gnu.org/issue/36924

On Sun, 04 Aug 2019 at 23:00, Ricardo Wurmus <rekado@elephly.net> wrote:

Is it still an issue?

Cheers,

simon

zimoun schreef op wo 23-03-2022 om 12:28 [+0100]:

IIRC, I encountered the same symptom (although perhaps with a different

cause, and I did not know if was caused by upgrades) last time I used

Guix System, which was in the 2022 or at least 2021, so I think it

might still be an issue. Or maybe it has been solved since then.

Greetings,

Maxime.

Am Mittwoch, dem 23.03.2022 um 12:28 +0100 schrieb zimoun:

If I recall correctly, the offending caches have not been updated

since, so the short answer is "we don't know". The files in my

/var/lib/gdm have some quite old dates, some of them ranging as far

back as 2019, so I suppose there still exists an issue potential.

Cheers

Hi Maxime and Liliana,

On Wed, 23 Mar 2022 at 13:48, Maxime Devos <maximedevos@telenet.be> wrote:

On Wed, 23 Mar 2022 at 21:22, Liliana Marie Prikler <liliana.prikler@gmail.com> wrote:

Thanks for your feedback.

Hum, do we keep a report open based on « maybe » or « we don’t know » or

« I suppose »? It is an honest question and not a rhetoric one. :-)

Well, how is this bug report actionable? Other said, what is missing as

concrete information for closing.

From my understanding of your feedback, the current answer to « Is it

still an issue? » seems « no ». It does not mean that a bug is not

around – so many bugs are around ;-) – but it means that this bug is not

a blocking issue, again from my understanding.

Could you confirm that the bug is appearing for you? Else, let close it

and reopen once the bug appears. WDYT?

Cheers,

simon

Hi,

On Wed, 23 Mar 2022 at 23:14, zimoun <zimon.toutoune@gmail.com> wrote:

I am proposing to close if no objection.

Cheers,

simon

tags 36924 + moreinfo

quit

zimoun <zimon.toutoune@gmail.com> writes:

I agree because it is not actionable as it is now.

--

Ricardo