From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6521316140522668032 X-Received: by 10.28.52.133 with SMTP id b127mr366956wma.13.1518421354087; Sun, 11 Feb 2018 23:42:34 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 10.28.214.21 with SMTP id n21ls885546wmg.0.canary-gmail; Sun, 11 Feb 2018 23:42:33 -0800 (PST) X-Google-Smtp-Source: AH8x227b1DgXCf0nsE1t76TiIvBUAkKig8g6Lhx+i+Xmxahu8AFzjTBI0FoF5aY07vRe8LsmAauQ X-Received: by 10.28.160.18 with SMTP id j18mr333681wme.15.1518421353462; Sun, 11 Feb 2018 23:42:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518421353; cv=none; d=google.com; s=arc-20160816; b=JVBSatew6i4ZzbtBu14+WWbJNA71bsUBmK3nvjjXcFHEfwlUxn0/uP2bpCVe43ASUd 0nul/3g8n6gMMylasTip89JN70a1gqH2xTfgKn6cchrSHediOQRPTPoYYZaeQq8hiS9U b9gUB7xxjyBtZO4eZDadMf2bRYJa2wzAbZzCQyUGxPiNFDcva3o2Ys21L/mjC5khwEAq 7a0W6MZD24lLRA/GnPIGuloDEDvAsKya0apNpXPbynolCN/Ex49QxGrxaWO+tl+FT/qO YYPxvGFlZ5SfJ6rbzGOb/i2flmlPQd9ryXSq2pwguQx96O9fiMLuTBmz+dZBeZPZFlBS 9j0g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:to:subject :arc-authentication-results; bh=9JdvD+PIJKjWigf/Xdy4HzPuGhrhyb9NMGj7RKn0wFE=; b=XBd5ofcGG/BF+1UcBUHBv4301pO5rendiE5rFhYEwtJEA0R1iqM3MooCCWd417YtI6 mgPlf/no72N4TahJ2HgMxKTDk8/ZE/BxmEKWgTB3jSSpjs/iLhF1GjtITKxjCTTaruX9 o9xcardcd9iJ2T4Ee0VoCxdnMbu0c/mC8Rhyvaszl8ztTNfms6X1KZC2Wvi+inir4Az3 s7m3PsuIiASNw3sn1TdDoLQMcCCgqkGeEo1B9sLGvawM0DWV2Vk4Oiu3dHfwpGclGpil YjXIqzz5fAmIiNa9QyykMimt0O/O/i9eNNmPJjR3OyanOk/Te8JViqlD2jhmlfCLcG9A y8aQ== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com Return-Path: Received: from goliath.siemens.de (goliath.siemens.de. [192.35.17.28]) by gmr-mx.google.com with ESMTPS id k21si468848wrd.1.2018.02.11.23.42.33 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 11 Feb 2018 23:42:33 -0800 (PST) Received-SPF: pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.28 as permitted sender) client-ip=192.35.17.28; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id w1C7gWhc022432 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 12 Feb 2018 08:42:33 +0100 Received: from [167.87.31.168] ([167.87.31.168]) by mail3.siemens.de (8.15.2/8.15.2) with ESMTP id w1C7gWxU005096; Mon, 12 Feb 2018 08:42:32 +0100 Subject: Re: Build can sporadically fail due to dpkg contention in buildchroot To: Alexander Smirnov , isar-users References: <79bd216e-53ca-5485-4f6c-66050d08ed5f@siemens.com> <4d2b9322-54ed-ddff-739e-d0a3d5c6cc7b@ilbers.de> <040312d8-2496-dc62-5cbc-744dbf6e953c@ilbers.de> From: Jan Kiszka Message-ID: <9a978df9-2c52-7bd5-ad75-d6a1ff0269bc@siemens.com> Date: Mon, 12 Feb 2018 08:42:32 +0100 User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 In-Reply-To: <040312d8-2496-dc62-5cbc-744dbf6e953c@ilbers.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-TUID: Qm4TtHFWm71Y On 2018-02-11 19:44, Alexander Smirnov wrote: > > > On 02/11/2018 09:18 PM, Jan Kiszka wrote: >> On 2018-02-11 17:55, Alexander Smirnov wrote: >>> Hi, >>> >>> On 02/11/2018 06:17 PM, Jan Kiszka wrote: >>>> Hi all, >>>> >>>> I got this failure of example-hello:do_build already twice while doing >>>> rebuild tests with my kernel series (ie. with more independent >>>> buildchroot users): >>>> >>>> DEBUG: Executing shell function do_build >>>> Get:1 file:/isar-apt isar InRelease >>>> Ign:1 file:/isar-apt isar InRelease >>>> Get:2 file:/isar-apt isar Release [2,864 B] >>>> Get:2 file:/isar-apt isar Release [2,864 B] >>>> Get:3 file:/isar-apt isar Release.gpg >>>> Ign:3 file:/isar-apt isar Release.gpg >>>> Get:4 file:/isar-apt isar/main amd64 Packages [1,135 B] >>>> Reading package lists... >>>> W: The repository 'file:/isar-apt isar Release' is not signed. >>>> hostname: No address associated with hostname >>>> dh_testdir >>>> dh_testroot >>>> dh_prep >>>> dh_testdir >>>> dh_testroot >>>> dh_install >>>> dh_install: Compatibility levels before 9 are deprecated (level 7 in >>>> use) >>>> dh_installdocs >>>> dh_installdocs: Compatibility levels before 9 are deprecated (level 7 >>>> in use) >>>> dh_installchangelogs >>>> dh_compress >>>> dh_fixperms >>>> dh_installdeb >>>> dh_installdeb: Compatibility levels before 9 are deprecated (level 7 >>>> in use) >>>> dh_gencontrol >>>> dh_md5sums >>>> dh_builddeb >>>> dpkg-deb: building package 'hello-build-deps' in >>>> '../hello-build-deps_0.2_all.deb'. >>>> >>> >>> Good catch! >>> >>>> The package has been created. >>>> Attention, the package has been created in the current directory, >>>> not in ".." as indicated by the message above! >>>> dpkg: error: dpkg status database is locked by another process >>>> mk-build-deps: dpkg --unpack failed >>>> [...] >>>> >>>> So we have a concurrency problem when building over the same dpkg >>>> database. Looks like we need to synchronize (lock-protect) the >>>> access to >>>> it, which also means pulling out the dependency installation from the >>>> regular build step. Is that feasible at all? Any alternatives (besides >>>> retrying such builds...)? >>> >>> In general we could do this easily: >>> >>> 1. Split the content of build.sh into two functions, for example: >>>   - install_build_deps >>>   - build_package >>> >>> 2. Spit the bitbake do_build() into two tasks: >>> >>> do_install_build_deps() { >>>      ... build.sh install_build_deps ... >>> } >>> >>> addtask install_build_deps before do_build after do_unpack >>> >>> do_build_package() { >>>      ... build.sh build_package ... >>> } >>> >>> 3. Using bitbake synchronization primitives, protect the fist task from >>> parallel execution. >>> >>> If you are OK with this, I could do this tomorrow. >> >> I'm still concerned how well this will scale: >> >> a) We have additional users we already know of (linux-kernel.bbclass). >>     We will need to provide them the same means. >> >> b) There might be more users hidden in today's or future recipes... >> > > Now we have pipeline: >  - do_fetch, do_unpack, do_build. > > I propose to extend this pipeline by one extra task: >  - do_fetch, do_unpack, do_install_build_deps, do_build. > > These are the core tasks that have default payload defined in calsses, > so you should not touch them in custom recipes. > > For better scale-ability, a separate class could be created: > > 8<-- > > dpkg-build-deps.bbclass: > > do_install_build_deps() { >    ... call mk-build-deps > } > > addtask install_build_deps before do_build after do_unpack > > 8<-- > > So if you want this functionality in your class, for example in > dpkg.bbclass, so just include it. I can't imagine if we will have so > many different classes to build something... I'm concern about all dpkg calls. Are we sure there are no others to just query the database eg. which cannot fail? Otherwise, this sounds good to me. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux