Re: s6-envuidgid: Weird errors with GNU libc's getgrent() and endgrent()

From: Peter Pentchev <>
Date: Tue, 11 Jun 2019 11:20:13 +0300

On Tue, Jun 11, 2019 at 10:28:00AM +0800, Casper Ti. Vector wrote:
> On Mon, Jun 10, 2019 at 11:10:13PM -0300, Guillermo wrote:
> > /etc/nsswitch.conf is 'owned' by sys-libs/glibc, and Gentoo's default
> > comes directly from the libc's source package:
> So Gentoo follows the upstream more closely, and the upstream default
> would now result in the problem. I think this is definitely worth a
> glibc bug report.

If I understand the situation correctly - a libc function setting
errno to a non-zero value when *not* indicating failure in another
way - I don't think this really warrants a bug report: it might be
covered by the same POSIX text as the realloc() one that the Perl
folks hit recently:

Neither the glibc manual page nor the POSIX text say anything about
endgrent() setting errno or leaving it alone, so I think that this
might indeed be the case - it may turn out that it is unwise to
try to check errno after an endgrent() call, it may turn out that
endgrent() "cannot fail" or something like that, silly as it sounds.
Same for getgrent() when it has returned a non-null pointer - it seems
that it is unwise to check errno in that case.

> > This is interesting. It hints at the problem really being in the
> > upstream package. And you said that you added the 'db' service, so I
> > take it that it wasn't there by default. Is this Void's current
> > default /etc/nsswitch.conf?
> Yes, precisely.


Peter Pentchev  roam_at_{,,}
PGP key:
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13

Received on Tue Jun 11 2019 - 08:20:13 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:38:49 UTC