From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6739560601010307072 X-Received: by 2002:a17:906:57c3:: with SMTP id u3mr19030488ejr.303.1569850434186; Mon, 30 Sep 2019 06:33:54 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a17:906:d144:: with SMTP id br4ls2855940ejb.11.gmail; Mon, 30 Sep 2019 06:33:53 -0700 (PDT) X-Google-Smtp-Source: APXvYqyK5/eghU1cLRLsqOCIRSw1L9JaZ0mP0oqw/0qawyemGpzm6ngGBlgNuBgP98sTZjGMJkYM X-Received: by 2002:a17:906:18e2:: with SMTP id e2mr19176868ejf.129.1569850433741; Mon, 30 Sep 2019 06:33:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1569850433; cv=none; d=google.com; s=arc-20160816; b=hur+yJDoIn5+EUapX9QHPEuZ3LOonkyOIX4CUleO2BUzQMg6F82ja4kOJpwgdWCaNH BEWQRvkRVipmlBOHP8Hwt5c2AwrBTSp2radf/7TmagY3m1XbZFwyD2nZUQMq+ukOdRjI HS5u7nkjjwo/eJFfblV18TbH6oBYAz9hIBloLn+5NZOSF0K8WiR9CRXqZunC+/O6/Tqq uXnb9KeV7J01jHn1vG047PHDSgnJMg7P5msYtJ6q2bioY7mO1XHvqGm29cLpJ60vC5uP rvVwk376Sr3jXmf5XfWiTMHh5zzdHPiEzlWzplG/8gSBsPP3TOCkkSG4svFO8+sSu1tQ CGRg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:to:from:date; bh=uTN4rlHNABjIp+35EaqSoCGbrSKbpyj3MzzVqN1M23A=; b=OAuMoblmlBucbnTxGLUN3Tx67UuGcjy/ev0ghnWWj0qzF3rBGrm75xuOrQRcx0DtZ6 M9VtgmB196+ttfGkvMUCDxSl1hzkvfB3PkJzNxedWhGWEpCBby9cmXZyYctuOJETjJcl 4CXSXlfOZB/s7UUAjB83ZuBCThuuOR9xXlZbpErt+B73oKNnmhuuX7Drk4oWW+NRAR3E u+ZmC5JqazYO1o0p5qwwZ9zg/3yQsKWzbyA3v2xKQwLoC1ZFDvDIYhrXjNEFiZdBUVj7 iHtdqCt0zJEgHkanHOl+aFD4QMMgU/8U4y2ni+kQt1Z/McQcrm7Pj1Uzhg2l2BUhqu25 C7Zw== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=neutral (google.com: 85.214.156.166 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) smtp.mailfrom=ibr@radix50.net Return-Path: Received: from shymkent.ilbers.de (shymkent.ilbers.de. [85.214.156.166]) by gmr-mx.google.com with ESMTPS id d27si897633ejt.1.2019.09.30.06.33.53 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 30 Sep 2019 06:33:53 -0700 (PDT) Received-SPF: neutral (google.com: 85.214.156.166 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) client-ip=85.214.156.166; Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 85.214.156.166 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) smtp.mailfrom=ibr@radix50.net Received: from yssyq.m.ilbers.de (host-80-81-17-52.static.customer.m-online.net [80.81.17.52]) (authenticated bits=0) by shymkent.ilbers.de (8.15.2/8.15.2/Debian-8) with ESMTPSA id x8UDXpPQ006474 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 30 Sep 2019 15:33:53 +0200 Date: Mon, 30 Sep 2019 15:33:51 +0200 From: Baurzhan Ismagulov To: isar-users@googlegroups.com Subject: Re: [PATCH v5 19/27] dpkg-base: Wait for umount to succeed Message-ID: <20190930133351.ceovfo27npbygcgt@yssyq.m.ilbers.de> Mail-Followup-To: isar-users@googlegroups.com References: <94b59dd0e5a14ece5f2d6b7131984ba944350b08.1569176231.git.jan.kiszka@siemens.com> <20190930110730.q4zxjwubhl53vtgi@yssyq.m.ilbers.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on shymkent.ilbers.de X-TUID: /q8DcKs2X4J8 On Mon, Sep 30, 2019 at 02:22:06PM +0200, Jan Kiszka wrote: > > I agree that we shouldn't ignore failing umounts. However, hanging forever > > leads to bad user experience. I suggest to introduce a timeout or a number of > > attempts and fail. > > Let's not over-engineer: CI runs have top-level timeouts, tuned to the > requirements of the particular runtime environment. Local builds have > ctrl-c. And defining such a micro-timeout would not be trivial as well. So > let's merge and look that this again when this really shows up, based on > that concrete case. My main concern is that 1. the user isn't immediately aware of the fact that something is going wrong, and 2. once aware, it isn't trivial to understand what is going on. Aborting the build won't make the user understand the problem. With wheezy or jessie, we had apt hanging. ATM, Jenkins workspaces leave gpg-agent running. Similar issues could occur in the chroot at any time. When it happens, the analysis would take some time; the idea is to reduce it to zero. This can be as simple as issuing a warning mentioning $0, which dir can't be umounted, and the fact that we wait infinitely for that, e.g. once a second. With this, the user could even salvage his build by killing the relevant processes. I think this is an important usability issue with a simple mitigation. If necessary, I could provide a patch. With kind regards, Baurzhan.