public inbox for isar-users@googlegroups.com
 help / color / mirror / Atom feed
From: Anton Mikanovich <amikan@ilbers.de>
To: Jan Kiszka <jan.kiszka@siemens.com>, isar-users@googlegroups.com
Subject: Re: [PATCH v1 3/5] dpkg: Remove unmount loop
Date: Tue, 17 Aug 2021 16:02:16 +0300	[thread overview]
Message-ID: <96a7a839-7b1e-61a9-1aed-184aafcfd6ba@ilbers.de> (raw)
In-Reply-To: <18078814-c9c0-b46b-af32-17058c39f036@siemens.com>

08.07.2021 15:21, Jan Kiszka wrote:
> On 07.07.21 18:38, Anton Mikanovich wrote:
>> Remove while loop when trying to unmount WORKDIR. Any failures of
>> umount should be investigated to fix the root cause.
>> Also make dpkg_undo_mounts do not fail if dpkg_do_mounts was not
>> called or it was called twice.
>>
> 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

We've reproduced the issue fixed by 17d0842d on the old code (pre-17d0842d).
The issue was caused by unmounting buildchroot mounts without care of 
their usage.
The latest v5 patchset is not affected, because there is no global task 
fail handling, and per-task unmount is protected by the reference counting.

Moreover, buildchroot_undo_mounts was moved after the while loop in 
dpkg_undo_mounts in v5, so it will not fail immediately like we had it 
with '/sys/fs/cgroups is busy' failures (the real fix of 
'/sys/fs/cgroups is busy' is still in progress).

-- 
Anton Mikanovich
Promwad Ltd.
External service provider of ilbers GmbH
Maria-Merian-Str. 8
85521 Ottobrunn, Germany
+49 (89) 122 67 24-0
Commercial register Munich, HRB 214197
General Manager: Baurzhan Ismagulov


  parent reply	other threads:[~2021-08-17 13:02 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-07 16:38 [PATCH v1 0/5] Restore downstream mounts compatibility Anton Mikanovich
2021-07-07 16:38 ` [PATCH v1 1/5] Revert "dpkg: Make mount buildroot reliable" Anton Mikanovich
2021-07-08 12:16   ` Jan Kiszka
2021-07-07 16:38 ` [PATCH v1 2/5] mount: Allow calling unmount on not mounted paths Anton Mikanovich
2021-07-08 12:17   ` Jan Kiszka
2021-07-07 16:38 ` [PATCH v1 3/5] dpkg: Remove unmount loop Anton Mikanovich
2021-07-08 12:21   ` Jan Kiszka
2021-07-08 14:35     ` Anton Mikanovich
2021-07-08 16:16       ` Jan Kiszka
2021-08-17 13:02     ` Anton Mikanovich [this message]
2021-07-07 16:38 ` [PATCH v1 4/5] image: Add reference counter Anton Mikanovich
2021-07-07 16:38 ` [PATCH v1 5/5] events: Unmount all lost mounts at task fail Anton Mikanovich
2021-07-08 12:24   ` Jan Kiszka
2021-07-08 14:41     ` Anton Mikanovich
2021-07-08 16:28       ` Jan Kiszka
2021-07-12 16:08         ` Baurzhan Ismagulov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=96a7a839-7b1e-61a9-1aed-184aafcfd6ba@ilbers.de \
    --to=amikan@ilbers.de \
    --cc=isar-users@googlegroups.com \
    --cc=jan.kiszka@siemens.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox