From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: bug#36924: fixing GDM + GNOME Shell Date: Mon, 05 Aug 2019 16:36:18 +0200 Message-ID: <87h86vznkt.fsf__9783.16928246699$1565015836$gmane$org@elephly.net> References: <87tvawzlvq.fsf@elephly.net> <20190805071719.GB15819@E2140> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:38757) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hue6h-0003Wr-LX for bug-guix@gnu.org; Mon, 05 Aug 2019 10:37:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hue6g-00085k-L8 for bug-guix@gnu.org; Mon, 05 Aug 2019 10:37:03 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:55081) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hue6g-00085b-Il for bug-guix@gnu.org; Mon, 05 Aug 2019 10:37:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hue6g-0005Lf-Cg for bug-guix@gnu.org; Mon, 05 Aug 2019 10:37:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-reply-to: <20190805071719.GB15819@E2140> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Efraim Flashner Cc: guix-devel@gnu.org, 36924@debbugs.gnu.org Efraim Flashner writes: > On Sun, Aug 04, 2019 at 11:00:41PM +0200, Ricardo Wurmus wrote: >> Hi Guix, >> >> Today I again couldn=E2=80=99t log into my workstation after upgrading t= he >> system. I=E2=80=99m using GDM + GNOME Shell. >> >> At first GDM wouldn=E2=80=99t 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=C2=B9. 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=E2=80=A6), but I would very much like to av= oid adding even more hacks. >> GDM came up after a reboot, but I still couldn=E2=80=99t log in. Instea= d 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