From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: Re: fixing GDM + GNOME Shell Date: Mon, 05 Aug 2019 16:36:18 +0200 Message-ID: <87h86vznkt.fsf@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]:38693) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hue6E-0003Il-Kg for guix-devel@gnu.org; Mon, 05 Aug 2019 10:36:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hue6C-0007pt-Ap for guix-devel@gnu.org; Mon, 05 Aug 2019 10:36:34 -0400 Received: from sender-of-o51.zoho.com ([135.84.80.216]:21289) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hue6B-0007op-O2 for guix-devel@gnu.org; Mon, 05 Aug 2019 10:36:32 -0400 In-reply-to: <20190805071719.GB15819@E2140> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" 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