From owner-freebsd-ports@freebsd.org Wed Jul 8 21:53:41 2020 Return-Path: Delivered-To: freebsd-ports@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 09D6E356664 for ; Wed, 8 Jul 2020 21:53:41 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B2Cjv5rH7z47tF for ; Wed, 8 Jul 2020 21:53:39 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id 068Lrhut053218 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 8 Jul 2020 14:53:43 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id 068LrgPK053217; Wed, 8 Jul 2020 14:53:43 -0700 (PDT) (envelope-from fbsd) Date: Wed, 8 Jul 2020 14:53:41 -0700 From: bob prohaska To: "Janky Jay, III" Cc: freebsd-ports@freebsd.org Subject: Re: Gracefully killing and restarting a port build.... Message-ID: <20200708215341.GB52503@www.zefox.net> References: <20200708034703.GA50491@www.zefox.net> <941930819.28.1594197843269@localhost> <20200708153013.GA52503@www.zefox.net> <25c3b51c-6fa2-4d69-cb39-5ac7802fc658@unfs.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <25c3b51c-6fa2-4d69-cb39-5ac7802fc658@unfs.us> X-Rspamd-Queue-Id: 4B2Cjv5rH7z47tF X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net X-Spamd-Result: default: False [0.84 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.64)[-0.637]; NEURAL_HAM_LONG(-0.60)[-0.596]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_SHORT(0.17)[0.174]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_WWW(0.50)[] X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2020 21:53:41 -0000 On Wed, Jul 08, 2020 at 09:34:53AM -0600, Janky Jay, III wrote: > In the future, if you can, try using "screen" or "tmux" to run these > large builds in so you don't take the risk of losing the > terminal/console. Or, maybe I'm completely off-base as to how it was > lost to begin with. > AIUI, screen runs until the session terminates and then stops. In my case the controlling terminal was lost when the ssh connection broke. Thus, I think screen would have quit as well. Just why ssh connections keep breaking is a mystery of long standing. I've been blaming it on feeble wifi between my workstation (a Pi3B+) and WAP (D-Link DI524) but have no persuasive evidence. Not usually a big deal. The build was started using something like make [options] > make.log & so it kept beavering away after ssh gave up and still existed when I looked for it with ps -a. There were still other ssh connections open and running at the same time. Is there some way to re-attach a running background job to a new controlling terminal? Thanks for writing! bob prohaska > On 7/8/20 9:30 AM, bob prohaska wrote: > > On Wed, Jul 08, 2020 at 10:44:03AM +0200, Ronald Klop wrote: > >> > >> Kill the leaf nodes of the process tree. So kill the c++ processes. Or type ctrl-c if you have control of the terminal. > > In this case I'd lost control of the controlling terminal and didn't > > know how to recover it. After kill -9 of the initial make process > > I left the system standing overnight, to see if killing the original make > > process would eventually propagate down to the leaf nodes. It didn't. > > > > Then I used killall c++, and again, it killed the named processes, but other things, > > notably pkg, kept running. After waiting a few minutes they were killall-ed. > > A notation from ninja eventually showed up in the logfile saying "interrupted > > by user", so maybe ninja was the place to start shutting things down. > > > >> If you are running the compile in a jail (like poudriere) you might use "killall -j c++" or something similar. > > No room for a jail on a Pi, alas.... > >> Pkill can be usable also. > > Thank you, I didn't know about it. > >> BTW: How graceful a restart works is outside of the scope of the ports framework and depends a lot on the structure of the chromium build process itself. > >> > > Understood. This is the first time I've ever needed to kill a port build. > > Usually they die prematurely of natural causes! > > > > Thanks for your help > > > > bob prohaska > > > > _______________________________________________ > > freebsd-ports@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org"