From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6521316140522668032 X-Received: by 10.28.154.197 with SMTP id c188mr198553wme.16.1518374672075; Sun, 11 Feb 2018 10:44:32 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 10.28.231.15 with SMTP id e15ls676249wmh.8.gmail; Sun, 11 Feb 2018 10:44:31 -0800 (PST) X-Google-Smtp-Source: AH8x226yiM28mqYMxl2pSTuHGr6oCsyiO8fGQlTlF3Q0ANQedzOLZ/KkQc1qlBapIB9fUGK+MsfL X-Received: by 10.28.116.24 with SMTP id p24mr221653wmc.6.1518374671534; Sun, 11 Feb 2018 10:44:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518374671; cv=none; d=google.com; s=arc-20160816; b=Yvnlykt3vIBjNAwJFyuvpo6/sMKXAZsvWu1C3jwxJ3cMHavgL7qN6TConXO2VhHo4L 6SvB2f/aC7J3jvbfBLIlLIN+BN0Nd1eQSrtixQSfntF4+yZKHcjnRr7XCEu4KnuZ1xIW p52uin+i6zUnvryCrP12ngBDyomhE2vOIU550C8iSNAZa0YYvNjG/jKw1UOvl77bQ6Zd q6nPyzWJsiOHNKSkp0/mKIH9mAZsYA9nhhgSrSyRbTEgI+sJDc382ahso7vF5ZDoy6aI 9RWa29SvJOxVhOkd/V27pBj9bmiEWHVydKlBdlp66HgtbbKl5WaDs/3KFGzVHxy5D7SA dTWQ== 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=GBBuKJm5vJCbg/EJqwaX1xYft+xW1XAihnHm5fkg+SY=; b=x4rYfq3n1kVRN5T0u1PeT/kYu0ihZA0xcMobFt5hmDpUXGhZ5vzfNDzv9NIYKzGXff Huu+A0FHUkosvNxYBNNhTVvzJApPXf5faUVJ58UZJBWueO03FK9/WICsk38H0ioICDfk G4Eyf/PMj+LkOOoXy9ZbqB0lB8bJD/17GiPUtuYX9F7YKyYTfXvYlE+US5kJgrIxLhlk kQCF6apUrpkLfeDl/Q/Sp3UVwehD/GBxrqk0vI8ez+FjpUEfODoxT19Dt+heEYYz6tT/ mqdAUCrOT3OGwfVMMsnEhpSddGONgIIKDmwLhZkunGOVD/EV4sZ/lSMjGdqf36DhuAP5 m8Zg== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: best guess record for domain of asmirnov@ilbers.de designates 85.214.62.211 as permitted sender) smtp.mailfrom=asmirnov@ilbers.de Return-Path: Received: from aqmola.ilbers.de (aqmola.ilbers.de. [85.214.62.211]) by gmr-mx.google.com with ESMTPS id c11si447120wrb.0.2018.02.11.10.44.31 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 11 Feb 2018 10:44:31 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of asmirnov@ilbers.de designates 85.214.62.211 as permitted sender) client-ip=85.214.62.211; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: best guess record for domain of asmirnov@ilbers.de designates 85.214.62.211 as permitted sender) smtp.mailfrom=asmirnov@ilbers.de Received: from [10.0.2.15] ([188.227.110.165]) (authenticated bits=0) by aqmola.ilbers.de (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id w1BIiSB7029667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 11 Feb 2018 19:44:29 +0100 Subject: Re: Build can sporadically fail due to dpkg contention in buildchroot To: Jan Kiszka , isar-users References: <79bd216e-53ca-5485-4f6c-66050d08ed5f@siemens.com> <4d2b9322-54ed-ddff-739e-d0a3d5c6cc7b@ilbers.de> From: Alexander Smirnov Message-ID: <040312d8-2496-dc62-5cbc-744dbf6e953c@ilbers.de> Date: Sun, 11 Feb 2018 21:44:23 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-TUID: 7720KFsK7umj 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... Alex