It is a magical namespace, in that it comes from libc, not from the kernel. Please make sure that you’ve installed a more recent libc, I guess? I just did a full build and install, and I’m unable to replicate the problem. Maybe there’s a static-linked pkg running around somewhere? I’m at a loss for better ideas.
Scott > On Nov 15, 2020, at 12:30 PM, Brandon Bergren <bdra...@freebsd.org> wrote: > > I think the problem is that user.* is somehow magically namespaced, so doing > a "dumb" sysctlbyname will get the wrong one. > > sysctl (the tool) does: > __sysctl("sysctl.name2oid > user.localbase",2,0xfffffbfffde98,0xfffffbfffda98,0x810809000,14) = 0 (0x0) > __sysctl("sysctl.oidfmt > user.localbase",4,0xfffffbfffdef8,0xfffffbfffd690,0x0,0) = 0 (0x0) > __sysctl("sysctl.name { 8.21 }",4,0xfffffbfffc8f8,0xfffffbfffc480,0x0,0) = 0 > (0x0) > __sysctl("sysctl.oidfmt > user.localbase",4,0xfffffbfffd0f8,0xfffffbfffc488,0x0,0) = 0 (0x0) > __sysctl("user.localbase",2,0x0,0xfffffbfffc480,0x0,0) = 0 (0x0) > __sysctl("user.localbase",2,0x81080a000,0xfffffbfffd0f8,0x0,0) = 0 (0x0) > > and picks up /usr/local. > > whereas libutil is currently just doing > __sysctlbyname("user.localbase",14,0xfffffbfffd4f8,0xfffffbfffd440,0x0,0) = 0 > (0x0) > > which is returning the builtin "" from the static kernel variable. > > On Sun, Nov 15, 2020, at 1:26 PM, Jessica Clarke wrote: >> On 15 Nov 2020, at 19:10, Brandon Bergren <bdra...@freebsd.org> wrote: >>> >>> On powerpc64 and powerpc64le, there is some really weird behavior happening >>> around the sysctl itself: >>> >>> root@crow:~ # pkg >>> The package management tool is not yet installed on your system. >>> Do you want to fetch and install it now? [y/N]: N >>> root@crow:~ # sysctl user.localbase >>> user.localbase: /usr/local >>> root@crow:~ # pkg >>> The package management tool is not yet installed on your system. >>> Do you want to fetch and install it now? [y/N]: N >>> root@crow:~ # sysctl user.localbase=/usr/local >>> user.localbase: /usr/local -> /usr/local >>> root@crow:~ # pkg >>> pkg: not enough arguments >>> Usage: pkg [-v] [-d] [-l] [-N] [-j <jail name or id>|-c <chroot path>|-r >>> <rootdir>] [-C <configuration file>] [-R <repo config dir>] [-o var=value] >>> [-4|-6] <command> [<args>] >>> >>> For more information on available commands and options see 'pkg help'. >>> root@crow:~ # >>> >>> >>> I would double check very closely that the sysctl is being called >>> correctly, the sysctl tool manages to read it out, but libutil does not. >> >> That's odd. What does truss say? >> >> Jess >> >>> On Sun, Nov 15, 2020, at 1:06 PM, Scott Long wrote: >>>> >>>>> On Nov 15, 2020, at 12:01 PM, Jessica Clarke <jrt...@freebsd.org> wrote: >>>>>> >>>>>> I felt similar concerns, but my misunderstanding of strlcpy() drove the >>>>>> result. Since the use case for getlocalbase() lends itself to also use >>>>>> strlcat()/strlcpy(), I was trying to replicate the API semantics of >>>>>> those, >>>>>> at least to the limit of my understanding. Thanks for the feedback, I’ll >>>>>> look at it some more. >>>>> >>>>> Thanks. ENOMEM also feels inappropriate as no allocation is taking >>>>> place. Perhaps ENAMETOOLONG, which is used in similar cases for things >>>>> like gethostbyname? Though sysctlbyname uses ENOMEM instead... sigh. >>>>> >>>> >>>> Yep, I wasn’t happy with ENOMEM either but I couldn’t find anything better. >>>> >>>>> Also, if pathlen has already been checked against SSIZE_MAX (giving >>>>> EINVAL) and tmplen against pathlen there's no need to then check tmplen >>>>> against SSIZE_MAX. >>>>> >>>> >>>> Done. >>>> >>>>> I'd be happy to give a review on Phabricator if/when you have a new >>>>> patch. >>>>> >>>> >>>> https://reviews.freebsd.org/D27227 >>>> >>>> Thanks, >>>> Scott >>>> >>>> >>> >>> -- >>> Brandon Bergren >>> bdra...@freebsd.org >> >> > > -- > Brandon Bergren > bdra...@freebsd.org _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"