Date: Fri, 7 Aug 2026 21:44:51 -0700 (PDT) From: Don Lewis <truckman@FreeBSD.org> To: "Herbert J. Skuhra" <herbert@gojira.at> Cc: Alan Somers <asomers@FreeBSD.org>, src-committers@FreeBSD.org, dev-commits-src-all@FreeBSD.org, dev-commits-src-main@FreeBSD.org, Jitendra Bhati <bhatijitendra2022@gmail.com> Subject: Re: git: 4bd01d6ae016 - main - fts: refactor to use fd-relative operations internally Message-ID: <tkrat.5ec6c9e217955834@FreeBSD.org> In-Reply-To: <87bjbiysvw.wl-herbert@gojira.at> References: <6a70e844.251cb.6995429f@gitrepo.freebsd.org> <87bjbiysvw.wl-herbert@gojira.at>
index | next in thread | previous in thread | raw e-mail
On 4 Aug, Herbert J. Skuhra wrote: > On Mon, 03 Aug 2026 21:13:08 +0200, Alan Somers wrote: >> >> The branch main has been updated by asomers: >> >> URL: https://cgit.FreeBSD.org/src/commit/?id=4bd01d6ae01632501b63438b8d9a401db9744a78 >> >> commit 4bd01d6ae01632501b63438b8d9a401db9744a78 >> Author: Jitendra Bhati <bhatijitendra2022@gmail.com> >> AuthorDate: 2026-06-12 17:07:55 +0000 >> Commit: Alan Somers <asomers@FreeBSD.org> >> CommitDate: 2026-08-03 19:12:28 +0000 >> >> fts: refactor to use fd-relative operations internally >> >> Replace all _open() calls with _openat() in __fts_open(), fts_read(), >> and fts_children(). Replace statfs() with _fstatfs(). >> >> Add fts_dirfd to struct _ftsent, set to the file descriptor of the >> parent directory. Callers can use openat(ent->fts_dirfd, ent->fts_name, >> ...) to access files safely without relying on fts_accpath, which >> enables programs in capability mode to open the files described by >> _ftsent. >> >> This is a preparatory change for fts_openat() which will allow callers >> to provide a pre-opened directory fd, enabling fts(3) traversal inside >> Capsicum capability mode. >> >> Mirror all fts_open() changes to fts_open_b(). >> >> As a result of expanding _ftsend, publish new ELF symbol versions for >> fts_openat and related functions. >> >> Sponsored by: Google LLC (GSoC 2026) >> Reviewed by: asomers >> Pull Request: https://github.com/freebsd/freebsd-src/pull/2303 >> --- >> include/fts.h | 2 + >> lib/libc/gen/Makefile.inc | 1 + >> lib/libc/gen/Symbol.map | 18 +- >> lib/libc/gen/fts-compat15.c | 1355 +++++++++++++++++++++++++++++++++++++++++++ >> lib/libc/gen/fts-compat15.h | 97 ++++ >> lib/libc/gen/fts.3 | 18 +- >> lib/libc/gen/fts.c | 49 +- >> 7 files changed, 1519 insertions(+), 21 deletions(-) > > This change seems to break poudriere: > > [00:00:04] Recording filesystem state for prepkg...mtree: ./bin: No such file or directory > [ERROR] Unhandled error! > [00:00:04] Cleaning up > [00:00:04] Unmounting file systems > Exiting with status 1 I am seeing a different error with poudriere-devel: [00:00:01] Starting jail CURRENTamd64-default Updating /var/run/os-release done. [00:00:02] Will build as nobody:nobody (65534:65534) [00:00:03] Ports supports: FLAVORS SUBPACKAGES SELECTED_OPTIONS [00:00:03] Acquiring build logs lock for CURRENTamd64-default... done [00:00:03] Logs: /var/poudriere/data/logs/bulk/CURRENTamd64-default/2026-08-07_15h29m37s [00:00:03] Loading MOVED for /var/poudriere/data/.m/CURRENTamd64-default/ref/usr/ports [00:00:03] Gathering ports metadata [00:00:03] Warning: (misc/freebsd-release-manifests): jexec: jail_attach(41): Operation not permitted [00:00:03] Warning: (misc/freebsd-release-manifests): Error: Error looking up dependencies for misc/freebsd-release-manifests [00:00:03] Warning: (ports-mgmt/pkg): jexec: jail_attach(41): Operation not permitted [00:00:03] Warning: (ports-mgmt/portconfig): jexec: jail_attach(41): Operation not permitted [00:00:03] Warning: (ports-mgmt/pkg): Error: Error looking up dependencies for ports-mgmt/pkg [00:00:03] Warning: (ports-mgmt/portconfig): Error: Error looking up dependencies for ports-mgmt/portconfig [00:00:03] Error: /usr/local/share/poudriere/bulk.sh:gather_port_vars:184:Fatal errors encountered gathering ports metadata [CURRENTamd64-default] [2026-08-07_15h29m37s] [crashed] Time: 00:00:01 [00:00:03] Logs: /var/poudriere/data/logs/bulk/CURRENTamd64-default/2026-08-07_15h29m37s When I upgraded my pkg build machine from 3abd3d3cf3f034cb3d4250a95a8d6c41e72971ef to 30ccf2f48c11e54fc0540510dcec7cd006a2c366, I found that poudriere-devel started having jexec failures. I suspected a kernel problem and started to set things up to track down the offending commit. I was surprised to find that using the old world 3abd3d3cf3f034cb3d4250a95a8d6c41e72971ef with the new 30ccf2f48c11e54fc0540510dcec7cd006a2c366 kernel did not have this problem, which makes this look like a userland problem. I did a git bisect to find the problematic commit by doing: make buildworld make installworld cd /usr/ports/ports-mgmt/poudriere-devel && make clean reinstall poudriere bulk -j CURRENTamd64 -C ports-mgmt/poudriere-devel at each step. I did the poudriere-devel build and reinstallation so that it is propertly built against and linked to the newly installed world. The result of the final poudriere bulk determines whether the iteration is a pass or a fail. Any failures of the earlier steps are handled as skips. When I ran git bisect, I got this result: 4bd01d6ae01632501b63438b8d9a401db9744a78 is the first 'bad' commit commit 4bd01d6ae01632501b63438b8d9a401db9744a78 Author: Jitendra Bhati <bhatijitendra2022@gmail.com> Date: Fri Jun 12 22:37:55 2026 +0530 fts: refactor to use fd-relative operations internally poudriere-devel runs jexec on the host and not in the jail. I think the permission error should only happen if jexec is run by a user other than root. I added some debug output to the poudriere internal scripts and it looks like the uid is root. I don't know why jexec would be sensitive to fts, since jexec does not use it: %ldd /usr/sbin/jexec /usr/sbin/jexec: libjail.so.1 => /lib/libjail.so.1 (0x3704d89e7000) libutil.so.10 => /lib/libutil.so.10 (0x3704d8ae3000) libc.so.7 => /lib/libc.so.7 (0x3704d9af8000) libsys.so.7 => /lib/libsys.so.7 (0x3704da328000) [vdso] (0x3704d7516000) I see that a fix to fts was committed, but uupgrading to commit 2ae8976a3f6a7e4deb1905326145f5c2575264f4 Author: Gleb Smirnoff <glebius@FreeBSD.org> Date: Fri Aug 7 13:46:22 2026 -0700 ocs_fc: return correct error code from ocs_hw_set_persistent_topology() did not make a difference. I'm stumped.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?tkrat.5ec6c9e217955834>