From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6629320495720300544 X-Received: by 2002:adf:eb49:: with SMTP id u9-v6mr2603884wrn.4.1543938173438; Tue, 04 Dec 2018 07:42:53 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a5d:5088:: with SMTP id a8ls5532241wrt.14.gmail; Tue, 04 Dec 2018 07:42:52 -0800 (PST) X-Google-Smtp-Source: AFSGD/WpLi9bw7zMTb1WfP0H4b5QzYagXYlF/eIo9fLa0u3SiAObTXFzFZD/xBCP4RdptBNMFKv7 X-Received: by 2002:a5d:44d2:: with SMTP id z18mr2414252wrr.15.1543938172936; Tue, 04 Dec 2018 07:42:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543938172; cv=none; d=google.com; s=arc-20160816; b=r1sXe52ZPxCgqQ9P5+2LsBCszJ+Pwltptk6qJt7kR28+5Qpk/RLulCi1KHRNV4b833 HBNMs3y9txT4p/VvrtmnO5Ji11MBgoAbqFlmjv5XxdecrFGmbf97RkChFgEwAsu1yy83 gupnOZz7T6YMV5qMbVr8cKcLidbObJ/4SkZFes5mhpUUmlL6uDl0PXRU+1SmS00yRb59 3myFT2L04jL05DYAEPCV3pCntK17F0AV0SHKZL1BA9AitYyoEuK2REchUImRCjiDBo89 cMKyXpbn97lbhkoIbRZ+cxwhv/ju6sLN2Q1pwwGKU3ALHy2bdkO/qezGiVr9/3i5cu2x S+2g== 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:references:cc:to:from:subject; bh=IudtRr63bhIEprb6ocP/18RGJDSxF4UNL0UrmvZqeWU=; b=UTJWbZA5scF1MVzMGFC9z2QU/mhBOp42FCZgFFohQmXiQ1p7LEli6p5C+XzvSFuolM QzLFZ3dGDtAkGOLggg4WoLA+RnytOXIbTHYEwW/jsrWV1mCkYltlLFcucwM1rX42JN2p Cmlh3RREY86IwKXsltqSd66oZbP7sDtoj6iByk1jNPL4kHEoWboly3hKEVtzyHW4ALUN /6qrljZKrASAvnFE+7PJakCatuBnhmZldAtc+8iR9FIZzOb9TQp11u7JogiOJwAly9dp oUDPE7kZg65YqtDSURWP3YmDgKyJhb9YMr6AMYORTQmmZ4qOnJQ0y0shD3lWKub1sEwF hhKg== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.39 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com Return-Path: Received: from lizzard.sbs.de (lizzard.sbs.de. [194.138.37.39]) by gmr-mx.google.com with ESMTPS id p15si520906wrm.5.2018.12.04.07.42.52 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Dec 2018 07:42:52 -0800 (PST) Received-SPF: pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.39 as permitted sender) client-ip=194.138.37.39; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.39 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by lizzard.sbs.de (8.15.2/8.15.2) with ESMTPS id wB4Fgq75002362 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 4 Dec 2018 16:42:52 +0100 Received: from [167.87.41.97] ([167.87.41.97]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id wB4Fgp5M005852; Tue, 4 Dec 2018 16:42:52 +0100 Subject: Re: [PATCH] isar-bootstrap: Fix and cleanup bind mounting From: Jan Kiszka To: "Maxim Yu. Osipov" Cc: Henning Schild , isar-users , Cedric Hombourger References: <6f5714bc-d5f5-c08f-c408-b32bab9169fc@siemens.com> <20181129193929.61a35056@md1za8fc.ad001.siemens.net> <2229f975-0752-ebe3-c165-979e1d5864b2@siemens.com> <61a6a17c-06e0-a13b-591e-3ea8bc09632e@ilbers.de> Message-ID: <405c22d0-48cd-4ea4-4c1b-c78e6c5570ed@siemens.com> Date: Tue, 4 Dec 2018 16:42:51 +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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-TUID: Prt9Sy8l/h7a On 04.12.18 15:24, [ext] Jan Kiszka wrote: > On 04.12.18 11:49, Maxim Yu. Osipov wrote: >> On 12/3/18 3:59 PM, Jan Kiszka wrote: >>> On 30.11.18 10:20, Maxim Yu. Osipov wrote: >>>> Hi Jan, >>>> >>>> I've just tried this patch (on the 'next' with reverted patch d40a9ac0) and >>>> ran "fast" CI >>>> >>>> isar$mount | wc -l >>>> 34 >>>> >>>> isar$./scripts/ci_build.sh -q -f >>>> >>>> CI script hung on CI stage when dpkg-base is modified >>>> causing rebuilding recipes based on dpkg-base. >>>> >>>> The mount reports less (!) mount points than before launching the script. >>>> >>>> mount | wc -l >>>> 31 >>> >>> Any news on what's different on your side? Where exactly does your build >>> hang? Was your CI environment in a clean state when running this test? Before >>> the comment lots of things leaked. >> >> >> On my stretch laptop (i7-6820HQ CPU @ 2.70GHz (8 cores) with SSD)  the >> reported problem is reproducible (I rerun 'ci_build.sh -q -f' several times in >> clean state) it hung and with the less mount points (the mount points before >> and after running are attached). >> >> The strange thing that I observe two bitbake processes: >> >> myo      26373  0.0  0.3 153116 29732 pts/0    Sl+  12:31   0:01 python3 >> /home/myo/work/isar/src/trunk/isar/bitbake/bin/bitbake >> multiconfig:qemuarm-stretch:isar-image-base >> multiconfig:qemuarm64-stretch:isar-image-base >> multiconfig:qemuamd64-stretch:isar-image-base >> >> myo      26379  2.5  0.6 328476 50028 ?        Sl   12:31   0:40 python3 >> /home/myo/work/isar/src/trunk/isar/bitbake/bin/bitbake >> multiconfig:qemuarm-stretch:isar-image-base >> multiconfig:qemuarm64-stretch:isar-image-base >> multiconfig:qemuamd64-stretch:isar-image-base >> > > We run multiple bitbake sessions after each other. Maybe the first one never > terminates (get stuck), and that is also why the rm after the first session > fails. You need to stop the build there and analyse what is keeping the mount > points busy. Wait... If I terminate a build from inside the container (i.e. "natively") and then quickly try to delete the build artifacts, I can trigger that infamous empty /dev bug - on the host. That has always been the problem, and that is one reason why we encapsulate things into containers. The reason for this is that bitbake's cooker waits for the last sub-process to finish before it calls the cleanup hook that does all the unmounting. If you delete something before that, you step into the mount point and purge its content. That /may/ be the issue here as well as we run rm directly after bitbake. IOW: Possibly just a known limitation of current Isar design /wrt to unmounting in isar_handler() that now surfaces in CI. I would not be surprised you can resolve that by waiting for the last cooker instance to terminate before deleting tmp. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux