From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6982225001537601536 X-Received: by 2002:a05:6512:3193:: with SMTP id i19mr26222565lfe.415.1625760973673; Thu, 08 Jul 2021 09:16:13 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:ac2:508b:: with SMTP id f11ls487659lfm.2.gmail; Thu, 08 Jul 2021 09:16:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzq0VHNooO52Vo/7TPjXNl0Fu62e8eblba0tirGsnSUu+iArYHO5P2zKKyLxAO56o7fjYTu X-Received: by 2002:a05:6512:3b10:: with SMTP id f16mr4307586lfv.572.1625760972542; Thu, 08 Jul 2021 09:16:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1625760972; cv=none; d=google.com; s=arc-20160816; b=kqWUSgcY87Wv1dOldBmKaycjYVZOk/zicsPlKv3BLaC6nAUQ/oCQOiV3umoMGl90D6 HCU26RkhB8tf+hH+lNKW4kpuRJdCEhV506H2y2TYJ2xxrnvBvrOF2UFJDFNutWv7pGq5 jzFKjBCegqoGQcwR/i72VEP5aGB0g4UQXHLoQsw9mTqkf9zs/EuyN903t8Rq7NcPdYFF UizrxusFw8QKx9yafE7+/a7cvwRDoC4ZI7RAngbI2n4urE2BasHJFxzQWcrXXvvu3mHe Enj9DMjPnOGsYGAbtz2ybOF4MtTNkCZqjMibBd3bB2lswA7Sv5HqGYXKpY2BgD7Li7An Q3Ww== 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; bh=gBZhfoImSUhMszmPJix7OCj8hOBjEo4LBOluEGeAzOA=; b=mHFl6nypjKUKjHPp+mMptKbXhlH5Fu7Osf1wjJFBIEPendYqoS4D1AOsThwPpmnvCG ncKkCXClc8KDSBZWoRwQjNQ28xEw4kCjTTZABtfWpTrXjwh9ErUXaO6N8iilbMzWKbs4 NSpnav5ejiQyjCv4jNP9ijwg3SC0tCauHEFqP/Daiy9hJRlmu0wK2dmfXw3uCf0qdHHI a9Uibi4VfykqeuIPxvRIQGlbU2kUyu2NRWOjp5BDIUkryVL2HLKg+Ww91wEqus+PWY7y LSwN2hRSux5F7pKipscswFYUD4IcNHCaCwMcGFAj2o6ByX5fv06dFP6YZBj/Uh5cPijQ xeZQ== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.40 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from gecko.sbs.de (gecko.sbs.de. [194.138.37.40]) by gmr-mx.google.com with ESMTPS id i12si111182lfc.10.2021.07.08.09.16.12 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Jul 2021 09:16:12 -0700 (PDT) Received-SPF: pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.40 as permitted sender) client-ip=194.138.37.40; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.40 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by gecko.sbs.de (8.15.2/8.15.2) with ESMTPS id 168GGBox030678 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 8 Jul 2021 18:16:11 +0200 Received: from [167.87.42.31] ([167.87.42.31]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 168GGBbF000419; Thu, 8 Jul 2021 18:16:11 +0200 Subject: Re: [PATCH v1 3/5] dpkg: Remove unmount loop To: Anton Mikanovich , isar-users@googlegroups.com References: <20210707163851.204296-1-amikan@ilbers.de> <20210707163851.204296-4-amikan@ilbers.de> <18078814-c9c0-b46b-af32-17058c39f036@siemens.com> <9a6c1b19-c9ad-e2b7-fbbf-d3b0ae2dda88@ilbers.de> From: Jan Kiszka Message-ID: Date: Thu, 8 Jul 2021 18:16:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <9a6c1b19-c9ad-e2b7-fbbf-d3b0ae2dda88@ilbers.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: QGU+BsDN/exI On 08.07.21 16:35, Anton Mikanovich wrote: > 08.07.2021 15:21, Jan Kiszka wrote: >> This is very likely wrong: We know from the past (should be in the git >> history, e.g 17d0842d) that not all subprocesses started inside the >> chroot may have been terminated when we left it. That can cause >> significant delays between returning from chroot and finding non-busy >> mount points to complete all umounts. Now, if you silently fail umounts, >> you may find inconsistently mounted chroots on the next recipe that >> tries to remount them. Big fat warning sign...! >> >> Jan > > Is that really correct to left background processes running from chroot? > Even if it is, we need to control it not to let it run forever. > Not sure how to deal with that. Set maximum run time maybe? > See the commit I cited on how these issues were reproducible. The only way to get rid of all pending processes - besides waiting for them - was and likely still is putting them in containers. If you can confirm that those issues are gone and explain, why, we can obviously change the umounting scheme. But none of the patches so far acknowledge these issues, thus have a high potential to kicking us back to the point before the current lazy umounting scheme. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux