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

[Maxim Cournoyer]

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.

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