Re: Possible incompatible change with initgroups(3)?
Date: Sat, 20 Sep 2025 08:54:43 UTC
Hi Yasuhiro, > I checked commit log between b0e7b55a0e90 and b3468202994f, and found > following one. > > ---------------------------------------------------------------------- > commit 0b018cfd81d8 > Author: Olivier Certner <olce@FreeBSD.org> > AuthorDate: Tue Sep 16 17:52:20 2025 +0200 > Commit: Olivier Certner <olce@FreeBSD.org> > CommitDate: Wed Sep 17 14:16:06 2025 +0200 > > initgroups(3): Fix return value on allocation failure > > (snip) > ---------------------------------------------------------------------- > > According to commit message, it is likely that the commit introduces > some incompatibility with initgroups(3) and that it causes error > messages of Postfix. This commit has absolutely nothing to do with what you are observing: ---------------------------------------------------------------------- Sep 20 03:00:11 rolling-vm-freebsd1 postfix/qmgr[2634]: fatal: initgroups: Socket operation on non-socket Sep 20 03:00:11 rolling-vm-freebsd1 postfix/pickup[2635]: fatal: initgroups: Socket operation on non-socket Sep 20 03:01:00 rolling-vm-freebsd1 postfix/showq[66274]: fatal: initgroups: Socket operation on non-socket ---------------------------------------------------------------------- There is no sign of out-of-memory anywhere here. It is true that this commit introduces a slight incompatibility, but we sometimes do that for bug fixes and in this case there should be only benefits (programs test for failure either with 'error != 0', which hasn't changed, or 'error == -1', which now will work correctly, preventing the program to continue without the expected credentials, or 'error < 0', same). The culprit is without doubt https://cgit.freebsd.org/src/commit/?id=9dc1ac8691966480, whose purpose is precisely to restore initgroups(3) compatibility that was lost after getgroups(2)/setgroups(2) semantics change. Why the symbol versioning mechanisms we are leveraging there don't work as intended isn't yet clear (to me at least), but this is clearly a bug as our intent is precisely that nobody has to recompile anything for things to continue working as before. FYI, we are pursuing that in https://reviews.freebsd.org/D52641. Thanks and regards. -- Olivier Certner