GNU bug report logs - #32182
Login fail after core-update without reboot

Previous Next

Full log

View this message in rfc822 format

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 32182 <at> debbugs.gnu.org, Pierre-Antoine Rouby <pierre-antoine.rouby <at> inria.fr>
Subject: bug#32182: Login fail after core-update without reboot
Date: Thu, 16 Dec 2021 10:56:06 -0500

Hello,

Ludovic Courtès <ludo <at> gnu.org> writes:

[...]

>> I can think of several solutions:
>>
>>   1. Arrange for services to refer to /gnu/store/…-pam.d instead of
>>      /etc/pam.d.  This can maybe be achieved by modifying PAM such that
>>      these applications honor $PAM_DIRECTORY or something like that.
>>
>>   2. Add support for “service chain-loading” in the Shepherd and/or
>>      GuixSD.  The idea is that, for services that cannot be restarted
>>      right away because they are currently running, register code to
>>      upgrade the service next time it is restarted (see
>>      <https://bugs.gnu.org/30706>).  That way, when ‘login’ restarts
>>      after ‘reconfigure’, it’s the new ‘login’ service that would be
>>      restarted.
>
> That bit was implemented long ago with Shepherd service replacements.
> So at least, now, one can run ‘herd start term-tty1’ or similar to get a
> working login:

Point 2 doesn't seem to help in working around or fixing the related
#52533 though, correct?  Restarting the remote elogind or even
ssh-daemon doesn't work there, perhaps because 'guix deploy' wasn't able
to complete in the first place.

I guess that means we should look into fixing point 1., as you already
suggested.  On top of that I'd propose disabling PAM unless there's a
good reason to have it on by default; as I wrote in the other issue,
`man sshd_config' documents that by default in OpenSSH it is disabled.

Thanks,

Maxim

Previous Next

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