fixing GDM + GNOME Shell

fixing GDM + GNOME Shell

[Ricardo Wurmus]

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

Re: fixing GDM + GNOME Shell

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 2083 bytes --]

On Sun, Aug 04, 2019 at 11:00:41PM +0200, Ricardo Wurmus wrote:
> 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.

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¹.

> 
> 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 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.

> 
> 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?

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: fixing GDM + GNOME Shell

[Ricardo Wurmus]

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

> On Sun, Aug 04, 2019 at 11:00:41PM +0200, Ricardo Wurmus wrote:
>> 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.
>
> 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¹.

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.

>> 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 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.

Does anyone know why this happens at all?  What are the cached data?
Can we do without?

>> What can we do to make GDM and GNOME Shell more reliable?
>
> 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).

In my opinion generating a global /var/cache/fontconfig should be
prevented; removing it seems again like an avoidable hack.

--
Ricardo

Re: fixing GDM + GNOME Shell

[Mark H Weaver]

Hi Ricardo,

Ricardo Wurmus <rekado@elephly.net> writes:

> 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?

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

Re: fixing GDM + GNOME Shell

[Ricardo Wurmus]

Mark H Weaver <mhw@netris.org> 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.

Interesting.

> 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.

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

Re: fixing GDM + GNOME Shell

[Timothy Sample]

Hello,

Ricardo Wurmus <rekado@elephly.net> writes:

> Mark H Weaver <mhw@netris.org> 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.
>
> Interesting.

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

bug#36924: GDM, GNOME Shell, etc. break when there are stale caches

[zimoun]

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:

> 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?

Is it still an issue?


Cheers,
simon

Re: bug#36924: GDM, GNOME Shell, etc. break when there are stale caches

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 852 bytes --]

zimoun schreef op wo 23-03-2022 om 12:28 [+0100]:
> > 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?
> 
> Is it still an issue?

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.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: bug#36924: GDM, GNOME Shell, etc. break when there are stale caches

[Liliana Marie Prikler]

Am Mittwoch, dem 23.03.2022 um 12:28 +0100 schrieb zimoun:
> Hi,
> 
> This old bug [1] is there since a long time.  What is the status?
> 
> 1: <http://issues.guix.gnu.org/issue/36924>
> 
> [...]
> 
> Is it still an issue?
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