bug#32182: Login fail after core-update without reboot

[Maxim Cournoyer]

Hi again,

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

> Hello,
>
> Ludovic Courtès <ludo@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