From owner-freebsd-hackers@freebsd.org Sat Apr 7 16:52:59 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 68EBBF96D47 for ; Sat, 7 Apr 2018 16:52:59 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EBB4770BE2 for ; Sat, 7 Apr 2018 16:52:58 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 208a6246-3a84-11e8-91c6-33ffc249f3e8 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 208a6246-3a84-11e8-91c6-33ffc249f3e8; Sat, 07 Apr 2018 16:53:00 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w37GqqYl093505; Sat, 7 Apr 2018 10:52:52 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1523119972.89422.1.camel@freebsd.org> Subject: Re: [diskless] pkg takes 100% of a CPU From: Ian Lepore To: "Rodney W. Grimes" Cc: freebsd-hackers@freebsd.org Date: Sat, 07 Apr 2018 10:52:52 -0600 In-Reply-To: <201804071435.w37EZeqw008615@pdx.rh.CN85.dnsmgr.net> References: <201804071435.w37EZeqw008615@pdx.rh.CN85.dnsmgr.net> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit 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 16:52:59 -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 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. -- Ian