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

From: [email-masked] (Ludovic Courtès)
Date: Mon, 23 Jul 2018 15:17:07 +0200

Hello!

Pierre-Antoine Rouby <[email-masked]> skribis:

> I think login try to use glibc-2.27 but it's still configured to use
> glib-2.26. It's possible this issue come from '/etc/pam.d/login'.

Indeed.  The problem here is that ‘reconfigure’ updates /etc/pam.d, but
does not change the service definition of ‘login’, etc.  Thus, when
‘login’ restarts, it reads the new /etc/pam.d/login, which contains a
line like:

  session required /gnu/store/…-elogind-232.4/lib/security/pam_elogind.so 

Consequently, ‘login’ dlopens pam_elogind.so, which is linked against
the new libc, which eventually causes it to crash.

It’s a real issue on headless servers because you could lock yourself
out (‘sshd’ could have the same problem.)

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.

Thoughts?

Ludo’.