From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id AB08D1582EF for ; Sun, 09 Feb 2025 00:47:23 +0000 (UTC) Received: from lists.gentoo.org (bobolink.gentoo.org [140.211.166.189]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) (Authenticated sender: relay-lists.gentoo.org@gentoo.org) by smtp.gentoo.org (Postfix) with ESMTPSA id 8C3923430CB for ; Sun, 09 Feb 2025 00:47:23 +0000 (UTC) Received: from bobolink.gentoo.org (localhost [127.0.0.1]) by bobolink.gentoo.org (Postfix) with ESMTP id B99E011047E; Sun, 09 Feb 2025 00:46:18 +0000 (UTC) Received: from ciao.gmane.io (ciao.gmane.io [116.202.254.214]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by bobolink.gentoo.org (Postfix) with ESMTPS id 907A81103CB for ; Sun, 09 Feb 2025 00:46:17 +0000 (UTC) Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1tgvSf-0003OE-L5 for gentoo-user@lists.gentoo.org; Sun, 09 Feb 2025 01:46:13 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-user@lists.gentoo.org From: Nuno Silva Subject: [gentoo-user] Re: Question about compilation Date: Sun, 09 Feb 2025 00:46:08 +0000 Message-ID: References: <2361441.ElGaqSPkdT@rogueboard> <7166e50d-8bab-652d-80fb-bb954bff733a@gmail.com> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) X-Archives-Salt: 7c7fb38a-c5e6-4205-90c1-83722d2ccc3e X-Archives-Hash: 31046252bfd38b44e6a8c55be517bed4 On 2025-02-09, Dale wrote: > Michael wrote: >> On Saturday 8 February 2025 23:07:38 Greenwich Mean Time Jack wrote: >>> On 2025.02.08 14:00, Filip Kobierski wrote: >>>> On Saturday, February 8th, 2025 at 15:47, >>>> Jacques Montier wrote: >>>> >>>>> Is it possible to stop a compilation midway in the case of a very >>>>> long compilation and then resume it from the same point without >>>>> having to start over from the beginning ? >>> >>>> I think you are looking for SIGSTP or SIGSTOP but I think that's >>>> not exactly it. From what I know you cannot do that for emerge >>>> easily. For similar results you might want to set up ccache. >>>> https://wiki.gentoo.org/wiki/Ccache >>> >>> If you really mean just interrupting a compile, then you should be able >>> to stop with Ctl-C, and then start/continue by running make or ninja >>> again, assuming that is what is used for whatever you are compiling. >>> Ccache can help since most of the results of the previous compile >>> attempt will have been cached, and so will be completed more quickly >>> the next time, but it's not the same as continuing from where it was >>> interrupted. >>> >>> If, as Filip implies, you are asking about interrupting emerge, it's >>> easy enough to interrupt, but essentially impossible to continue from >>> where it left off. "emerge --continue" will just try to emerge every >>> package from the interrupted emerge which was not completed, but it >>> will start each one from scratch. What has often, but not alwasy >>> worked for me, is to use ebuild directly. "ebuild >>> .../path/to/package.ebuild compile" will figure out that everything >>> prior to the compile was completed, and then issue the make or ninja >>> commands, which will just pick up where they left off. If that does >>> work, then you need to repeat the ebuild, but with the install and then >>> the qmerge commands. The only problem with that (for me, at least) is >>> that ebuild does not leave exactly the same lines in emerge.log, so a >>> package installed that way will not show up in "gentlop -t package" >>> output. >> You can run 'ebuild merge', but this will only continue with the >> last package you were emerging when it was interrupted and it will continue >> from whatever stage the emerge was at the time it was interrupted. >> >> If your intention is to suspend/hibernate the OS halfway through an emerge and >> continue later on, then you can suspend the emerge job with job control: >> >> Ctrl+z >> >> After you wake up the system from suspend or reboot from hibernate you can >> bring the emerge job back into the foreground, so it can continue running from >> where you left it, by invoking: >> >> fg >> >> NOTE: Depending how many threads you were running before you suspended the >> emerge and how much swap was being used, you may need to wait for a few >> minutes for all the threads to pause. Keep an eye on top to confirm this has >> taken place and the CPU is now idle, before you suspend/hibernate the OS. If >> you don't you could discover the suspend/hibernate fails if you do not have >> enough RAM/space. > > > Would that survive a full reboot?  I'm asking about a regular desktop > top system.  It's rare but sometimes I am doing updates and have a power > failure and have to shutdown until power comes back.  I've always just > done a emerge --resume but that starts any unfinished emerges from > scratch.  Just curious if this would work.  If I can remember to do it > if it does.  ;-)  > > Dale > > :-)  :-)  No, that's shell job control, it will live only while the shell process lives, so wouldn't survive a shutdown/reboot. There were one or two FEATUREs that could be used to restart where it stopped, was it FEATURE="keepwork"? (I guess it's a bit like invoking the build system or ebuild directly on the partial build as mentioned upthread, but with the comfort of doing it through emerge.) -- Nuno Silva