GNU bug report logs - #52051
[core-updates-frozen] cannot login ('org.freedesktop.login1' service times out)

Previous Next

Full log

Message #88 received at 52051 <at> debbugs.gnu.org (full text, mbox):

From: Leo Famulari <leo <at> famulari.name>
To: Maxime Devos <maximedevos <at> telenet.be>
Cc: Timothy Sample <samplet <at> ngyro.com>, 52051 <at> debbugs.gnu.org,
 Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Subject: Re: bug#52051: [core-updates-frozen] cannot login
 ('org.freedesktop.login1' service times out)
Date: Tue, 21 Dec 2021 12:32:21 -0500

On Tue, Dec 21, 2021 at 04:52:19PM +0000, Maxime Devos wrote:
> Are there any good reasons for having a timeout at all?
> (Except for the local-user denial of service, but local users can do
> "guix build -f something-that-allocates-almost-all-memory-and-melts-
> the-cpu.scm" anyway ...)
> 
> If not, can the timeout be disabled/set to infinity?

Could be. But I think that, based on a several years of reports, the
X200 with an HDD is the slowest machine used with Guix System. On my
X200 with HDD, I have personally experienced similar race-y bugs that
seem to crop up after major upgrades --- I assume that it's a case of
bad luck, where important programs for booting move to distant parts of
the disk and seeking is too slow.

> A comment like 
> 
> > ;; Set timeout to a huge number (16.6 hours), because
> > ;; upstream often sets timeouts low for spinning disks,
> > ;; slow CPUs, etc.
> > (limit [...] "60000")
> 
> could be useful (I'm assuming the timeout is in seconds here).

I suggest we wait until such drastic action is necessary. Otherwise we
might be banging our heads against the wall in a few years, trying to
debug something. Let's not rush to extremes :)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.