From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 25965E00C5C; Thu, 3 Sep 2015 09:44:59 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on yocto-www.yoctoproject.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-HAM-Report: * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] Received: from dan.rpsys.net (5751f4a1.skybroadband.com [87.81.244.161]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id A620AE00BBA for ; Thu, 3 Sep 2015 09:44:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by dan.rpsys.net (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id t83Gil4c011520; Thu, 3 Sep 2015 17:44:47 +0100 Received: from dan.rpsys.net ([127.0.0.1]) by localhost (dan.rpsys.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id qCMN-WyEwy7N; Thu, 3 Sep 2015 17:44:47 +0100 (BST) Received: from [192.168.3.10] ([192.168.3.10]) (authenticated bits=0) by dan.rpsys.net (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id t83GiUTL011500 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 3 Sep 2015 17:44:42 +0100 Message-ID: <1441298670.24871.125.camel@linuxfoundation.org> From: Richard Purdie To: "Reyna, David" Date: Thu, 03 Sep 2015 17:44:30 +0100 In-Reply-To: <5E53D14CE4667A45B9A06760DE5D13D0826580BA@ALA-MBA.corp.ad.wrs.com> References: <5E53D14CE4667A45B9A06760DE5D13D082655EF5@ALA-MBA.corp.ad.wrs.com> <5E53D14CE4667A45B9A06760DE5D13D0826580BA@ALA-MBA.corp.ad.wrs.com> X-Mailer: Evolution 3.12.11-0ubuntu3 Mime-Version: 1.0 Cc: "toaster@yoctoproject.org" Subject: Re: Design - Cancelling builds X-BeenThere: toaster@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Web based interface for BitBake List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 16:44:59 -0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Thu, 2015-09-03 at 16:11 +0000, Reyna, David wrote: > The thing is that we have all done exactly that at one time or another > to stop an errant build, however Bitbake explicitly advises against > that. The reason is that it is possible that a given task could be > broken at a state that cannot be recovered from in a subsequent > build. > > And while that failure state has never been encountered in my > experience, it is always possible given how fancy bitbake is getting > around parallel builds and state management, and the actions to > recover from such a state would probably not be doable from Toaster > and would require the intervention of the system manager. Generally bitbake itself is comparatively safe however we have no guarantees about the underlying build systems in the individual pieces of software though. One pathologically bad case is when we run out of disk space, that usually breaks build directories to the point they're unusable, depending on where/when it happens. The same thing could happen when killing builds although the risk is smaller. Cheers, Richard