GNU bug report logs -
#32182
Login fail after core-update without reboot
Previous Next
Full log
Message #19 received at 32182 <at> debbugs.gnu.org (full text, mbox):
Hi again,
Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:
> 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.
Another bit that probably played a role here: the above failure to
complete is perhaps caused/made worst by #41238 (guix deploy close ssh
session after each store items sent), which doesn't reuse the same
stable SSH session to do the whole of what it needs to do.
Maxim
This bug report was last modified 3 years and 178 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.