From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6487873763254730752 X-Received: by 10.28.156.65 with SMTP id f62mr995334wme.16.1510583151795; Mon, 13 Nov 2017 06:25:51 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 10.223.144.209 with SMTP id i75ls6819653wri.12.gmail; Mon, 13 Nov 2017 06:25:51 -0800 (PST) X-Google-Smtp-Source: AGs4zMbw/C0QOfXRzgGuDHDTdUR0vFnHjyki852dsRtDhCuXdIE+i8U/p33h1HG00+aVc6tEEfM/ X-Received: by 10.28.156.76 with SMTP id f73mr27601wme.4.1510583151427; Mon, 13 Nov 2017 06:25:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1510583151; cv=none; d=google.com; s=arc-20160816; b=SWIZBBPBAaoQJDqOXstlprJy7NVcjL0wKpNMXO3C4yTteGBWbxNDnen9W7FNGgqN8d JAPs+0nFV+ySm06fJroYBn01DrfkQxL/h39f5y92476keTJ+iU+tKmZKh1ki7uvarGX5 ynkusLQEryLE4qJwGLXHPU7q3CST8zaXwtN1DS9MqjbVmqDS8yGSW6kvduhNhGKZF8+K UntZYdbdcCo1dDdVj3JT54Vd+QfLgByO4LUFo1LbFr0qpURUIVMMokvFjKBjMrvgdDeD LaN8FmzC+loJh62WqXZNhrC8A7PuZNXjjZquU1uHszbApZjjZskXPrB9LBPAZcjq+CL8 8z6w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:mail-followup-to:message-id :subject:to:from:date:arc-authentication-results; bh=P0zUiwb78N769OV84UfRiyRhANI5219SLzqXibaPhCg=; b=H/K5w6FCZZeEyDRlXsQEa68fnLjAxhUhR/AYkW8SyMqQJOa91oLjbXpFEpNIG3I6zZ v0levFnV1GP7qoqm0h2+Ty8zwOf8de1YPNNeBGD2q2jdyKBb95uinMsGemC8MQ/8wDhj /pKrcM+CQ/xBXyduDje6PI6aTSTEIeEdcOLqnLfGTjK/vKhfXVxC1+j29AronpPbBai4 q2ZtPwAsCVw83FPId1xKjUTwmH23uv8sFePvVd5VgMZ+w9hbCt0r8roTZ4FCmkEKDNg4 tSRVpFhOQI3Rayiur0qKH8P1kNW4fc2GZiPPAgwFFgjIbS4HBuuG1Dv2sdIpQ1TpC7Mn telw== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of christian.storm@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=christian.storm@siemens.com Return-Path: Received: from goliath.siemens.de (goliath.siemens.de. [192.35.17.28]) by gmr-mx.google.com with ESMTPS id o2si600497wmf.1.2017.11.13.06.25.51 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 06:25:51 -0800 (PST) Received-SPF: pass (google.com: domain of christian.storm@siemens.com designates 192.35.17.28 as permitted sender) client-ip=192.35.17.28; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of christian.storm@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=christian.storm@siemens.com Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id vADEPpGr032278 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 13 Nov 2017 15:25:51 +0100 Received: from localhost ([139.25.69.251]) by mail2.siemens.de (8.15.2/8.15.2) with ESMTPS id vADEPo0G024931 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 13 Nov 2017 15:25:50 +0100 Date: Mon, 13 Nov 2017 15:24:43 +0100 From: Christian Storm To: isar-users@googlegroups.com Subject: Re: [PATCH] isar-image-base: fix some dangling mounts Message-ID: <20171113142443.hczmlzhnlligt62m@MD1KR9XC.ww002.siemens.net> Mail-Followup-To: isar-users@googlegroups.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <875ca5fe-4116-ac26-bef6-20b6225aa809@ilbers.de> User-Agent: Mutt/20170113 (1.7.2) X-TUID: Q1I6fO0ToUE3 > [...] > Here I see that you insert quite similar patterns across the Isar code, > would it be better to have one global clean up function like? > > do_isar_mount_cleanup () { > if [ -d "${WORKDIR}/mnt" ]; then > # umount and remove > fi > > if [ -d "${WORKDIR}/rootfs/proc" ]; then > # umount and remove > fi > > if [ -d "${BUILDCHROOT_DIR}/proc" ]; then > # umount and remove > fi > > etc... > } > > This approach will significantly simplify maintenance of clean up traps > and adding of new possible mounts to Isar. What do you think? I'd say it depends :) It breaks if you rely on keeping something mounted while executing a child script that does unmount everything, following your proposal. If we can make sure that such a situation never occurs, we may consolidate this. For now, it's rather local just undoing the mounts done in the scope of the script. So, in the end, I think it's a matter of taste and contracts between the different parts of Isar. What one may consider to "de-duplicate" is a stack of mounted directories being pushed to and unmounted on script exit. So, something like push_umount ${IMAGE_ROOTFS}/proc and then the EXIT trap enumerates all those entries, unmounting them. The same has to be done for removing the directories, if applicable. Besten Gru�, Christian -- Dr. Christian Storm Siemens AG, Corporate Technology, CT RDA ITP SES-DE Otto-Hahn-Ring 6, 81739 M�nchen, Germany