Re: fixing GDM + GNOME Shell

[Ricardo Wurmus <rekado@elephly.net>]

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