Re: Bug#993821: After upgrading libc, some services are unable to restart (including systemd-resolved)
Hi,
On 2021-09-07 10:39, Michael Hudson-Doyle wrote:
> On Tue, 7 Sept 2021 at 10:21, Michael Biebl <biebl@debian.org> wrote:
>
> > Am 06.09.21 um 23:45 schrieb Vincent Bernat:
> > > Package: systemd
> > > Version: 247.9-1
> > > Severity: normal
> > >
> > > Hey!
> > >
> > > After upgrading to libc6 2.32-1, some services are unable to restart.
> > > In my case, systemd-resolved, systemd-timesyncd and colord. Using
> > > "systemctl daemon-reexec" fixes the issue. Unsure if there is really
> > > something to be fixed but as I didn't find anything about that, a bug
> > > report may help others. I suppose the problem is related to NSS.
> > >
> > > Sep 06 23:06:43 chocobo systemd[1]: Starting Network Time
> > Synchronization...
> > > Sep 06 23:06:43 chocobo systemd[236983]: systemd-timesyncd.service:
> > Failed to determine user credentials: No such process
> > > Sep 06 23:06:43 chocobo systemd[236983]: systemd-timesyncd.service:
> > Failed at step USER spawning /lib/systemd/systemd-timesyncd: No such process
> > >
> > >
> >
> >
> > @libc maintainers: any ideas what could be causing this? If this is
> > triggered by a libc6 update, should this be reassigned to glibc?
> >
>
> We went through this in Ubuntu recently and decided that restarting systemd
> in glibc's postinst was the safest option:
> https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1942276
>
> What's happening is that systemd is running with the old glibc, forks and
> then does NSS things that cause the new glibc's NSS modules to load and
> they don't necessarily work, leading to failures in any unit that specifies
> User=. At least for Ubuntu's builds the NSS modules seem to be ABI
> compatible between 2.32 and 2.33 (I didn't try 2.31 vs 2.32) but they are
> definitely not between 2.33 and 2.34.
Thanks for this feedback and the pointer to the patch used in Ubuntu. It
seems to be a good solution, and matches what is done for other init
systems.
On the other hand, the problem is supposed to only happen for major
glibc version upgrade where the NSS modules might have a different ABI.
In that regard, I would be tempted to restart it only for major versions
upgrade like it's done for other daemons. Now if the systemd maintainers
consider it's fine restarting it for each glibc upgrade, we should
probably go that way.
Regards,
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
Reply to: