From owner-freebsd-hackers@freebsd.org Sat Apr 7 17:08:33 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9D4A4F97F22 for ; Sat, 7 Apr 2018 17:08:33 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F41D579239; Sat, 7 Apr 2018 17:08:32 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w37H8TbR009360; Sat, 7 Apr 2018 10:08:29 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w37H8Ts8009359; Sat, 7 Apr 2018 10:08:29 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201804071708.w37H8Ts8009359@pdx.rh.CN85.dnsmgr.net> Subject: Re: [diskless] pkg takes 100% of a CPU In-Reply-To: <1523119972.89422.1.camel@freebsd.org> To: Ian Lepore Date: Sat, 7 Apr 2018 10:08:29 -0700 (PDT) CC: freebsd-hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2018 17:08:34 -0000 > On Sat, 2018-04-07 at 07:35 -0700, Rodney W. Grimes wrote: > > > > > > On Sat, 2018-04-07 at 11:50 +0200, BERTRAND Jol wrote: > > > > > > > > Steven Hartland a crit: > > > > > > > > > > > > > > > When we?ve seen it using 100% it?s been doing comprehension stuff which > > > > > usually finishes you just have to wait. Not sure if that?s what you?re > > > > > seeing? > > > > Yesterday, I have killed pkg after more than 100 hours of CPU time... > > > > > > > > Best regards, > > > > > > > > JB > > > For me, pkg(8) quit working on systems that have /var/db mounted from > > > nfs long ago, maybe as much as a year ago at this point. I mentioned > > > it on irc, and was told "It's probably something to do with locking", > > > but I already have boot.nfsroot.options="nolockd" in loader.conf > > > (because that's pretty much the only option because the rc(8) system > > > was broken years ago when it comes to nfsroot). > > My understanding of the current broken state of afairs is that pkg > > does not work over nfs unless you have proper and full lockd support, > > AND set NFS_WITH_PROPER_LOCKING in pkg's environment.??This really > > really really just needs to work without a lot of fuss out of the > > box. > > > > nfs locking support is compiled into the kernel on both the server and > client side, and rpc.lockd is running on both, but there is no need for > actual locking on the mount because the rootfs isn't accessed by > multiple clients at once -- each of my arm boards has its own private > rootfs exported from the server. I'm pretty sure I tried remounting > root pkg wants to do locking, multiple copies of pkg may be running on one client, you might get pkg to work for you if you do the echo "NFS_WITH_PROPER_LOCKING = true;" >> /usr/local/etc/pkg.conf I mentioned in my follow up. > > I agree that pkg(8) needs to just work. :-) > > The /etc/rc.initdiskless is presenty (11.x and later) in a usable > > state, though it has some issues if your /usr is seperate from /, > > and you have to override the default size of /var due to bloat, > > though I think the sizes of all the tmpfs's got bumped in ^head/. > > > > I don't want an mfs-based /var. I want /var, which is just a dir in the > rootfs, to work the way it's supposed to even if rootfs is nfs-mounted. > Changes to the rc(8) subsystem done long ago, related to managing > pidfiles, cause the bulk of the problems. The problem would be fixable > if we had an mfs-based /run filesystem mounted very early to hold such > things, then later during rc processing a symlink could be made so that > /var/run would point to /run. I'm afraid all of that is easy to say, > but probably has a zillion little nits and "that won't work in my crazy > setup" objections from people, so I've never pursued it seriously. I agree we should support a non mfs based /var. I'll take a crack at seeing how hard it is to turn that off. What about making /var/run mfs based when rc.initdiskless runs? I think you can actually get that done under the current scheme once I get /var turned off from doing the mfs/var.cpio.gz extract. Need to see if it processes conf/var/run/*, I do not think so. -- Rod Grimes rgrimes@freebsd.org