Hi again, Maxim Cournoyer <[email protected]> writes:
> Hello, > > Ludovic Courtès <[email protected]> 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
