From unknown Sat Sep 13 23:19:30 2025 X-Loop: help-debbugs@gnu.org Subject: bug#52516: Avoiding race condition between partprobe and getting PARTUUID using lsblk? Resent-From: Anton Hvornum Original-Sender: "Debbugs-submit" Resent-CC: bug-parted@gnu.org Resent-Date: Wed, 15 Dec 2021 15:59:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 52516 X-GNU-PR-Package: parted X-GNU-PR-Keywords: To: 52516@debbugs.gnu.org X-Debbugs-Original-To: bug-parted@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.163958389521664 (code B ref -1); Wed, 15 Dec 2021 15:59:02 +0000 Received: (at submit) by debbugs.gnu.org; 15 Dec 2021 15:58:15 +0000 Received: from localhost ([127.0.0.1]:33550 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mxWfW-0005dK-8Z for submit@debbugs.gnu.org; Wed, 15 Dec 2021 10:58:15 -0500 Received: from lists.gnu.org ([209.51.188.17]:43384) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mxU6t-0007BG-Ll for submit@debbugs.gnu.org; Wed, 15 Dec 2021 08:14:20 -0500 Received: from eggs.gnu.org ([209.51.188.92]:58776) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mxU6s-0008Ms-AB for bug-parted@gnu.org; Wed, 15 Dec 2021 08:14:19 -0500 Received: from smtpout-55.fbg1.glesys.net ([185.39.145.55]:63666) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mxU6q-0001Bq-0X for bug-parted@gnu.org; Wed, 15 Dec 2021 08:14:17 -0500 X-Sender-ID: b6e48cdc-5da8-11ec-ad1a-2d7ca687e8f6 X-Gm-Message-State: AOAM530ud7LxrPlE8OI+x1qAotkY81Xrt7VihL06SOjwIF9oV6IZ1WRV eZsZqFgWh8j1hjcMJWurvOQJq9ElhKHZmUbX6hE= X-Google-Smtp-Source: ABdhPJyFyfFiNpdNdBIy2ItJZ8p+7yKDLs2YANZuNzoyEIXg7VRp9Lw1whi5ADkrgJwpHIvWjiSwyUPbGXF6Cv/jGoI= X-Received: by 2002:a05:6214:d0e:: with SMTP id 14mr11028604qvh.10.1639573974024; Wed, 15 Dec 2021 05:12:54 -0800 (PST) MIME-Version: 1.0 From: Anton Hvornum Date: Wed, 15 Dec 2021 13:12:43 +0000 X-Gmail-Original-Message-ID: Message-ID: Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=185.39.145.55; envelope-from=anton@hvornum.se; helo=smtpout-55.fbg1.glesys.net X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Mailman-Approved-At: Wed, 15 Dec 2021 10:58:13 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) Hi. So I've been struggling a bit with optimizing applications calling partprobe right after lsblk to retrieve PARTUUID of newly generated partitions using parted. Assuming the following loop: * partprobe * lsblk * if !result: sleep + loop It feels as if every partprobe (indirectly or directly) flushes a cache/struct of information somewhere, which makes lsblk "fail" to retrieve certain information if executed too quickly in succession. A normal approach to solving this is adding a delay between partprobe and lsblk, something I wanted to avoid by putting the sleep at the very end of the loop, and instead do many quick loops until the information is available. I could also put partprobe before the loop, and continue looping until the information becomes available. But that poses an issue if the disk-operation (parted) completes after partprobe performs it's tasks. Leaving the loop in a dead state until a new partprobe is called (or that seems to be the issue at least). My question boils down to: 1. Is there a way to get an indication of when the partprobe (or kernel) has completed its task of populating the partition information? 2. Is there a way to tell partprobe/kernel to not clear the old struct before the new information is available (leaving "old information" intact until new exists, rather than wiping it and then populating) If none of the two above is possible, I would like to consider those being a feature as it would greatly help to verify when disk operations are 100% complete. I don't mind optionally hanging applications/scripts until parted is complete, as I would like to avoid continuing based on parted exit code if the exit code is not a guarantee of the process being completed in this case. Best wishes: Anton Hvornum From unknown Sat Sep 13 23:19:30 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Anton Hvornum Subject: bug#52516: closed (Re: bug#52516: Avoiding race condition between partprobe and getting PARTUUID using lsblk?) Message-ID: References: X-Gnu-PR-Message: they-closed 52516 X-Gnu-PR-Package: parted Reply-To: 52516@debbugs.gnu.org Date: Wed, 15 Dec 2021 16:56:03 +0000 Content-Type: multipart/mixed; boundary="----------=_1639587363-3571-1" This is a multi-part message in MIME format... ------------=_1639587363-3571-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #52516: Avoiding race condition between partprobe and getting PARTUUID usin= g lsblk? which was filed against the parted package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 52516@debbugs.gnu.org. --=20 52516: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D52516 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1639587363-3571-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 52516-close) by debbugs.gnu.org; 15 Dec 2021 16:55:11 +0000 Received: from localhost ([127.0.0.1]:33567 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mxXYd-0000tg-I1 for submit@debbugs.gnu.org; Wed, 15 Dec 2021 11:55:11 -0500 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:32174) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mxXYb-0000tW-O3 for 52516-close@debbugs.gnu.org; Wed, 15 Dec 2021 11:55:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1639587309; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=olJ1bjuaP/bGradBusCR8c4pRohjYe4MbJ+kz62XFPw=; b=NsswWQQW+cqtLSdeAX04JOe0dPEMMzTDtyUJTwh+1QgpZEJkfat0A9MUv8o9tD7mp94lPm jJVaDned5Sald4SopZv0NHC33NTaohlGTf2sxaSYA6Et6HKNoRZtX3tGWJzjAYUHtFuEAN UZQbRembOUqxtr8wRv7l/M1f+KZ/HLg= Received: from mail-pl1-f197.google.com (mail-pl1-f197.google.com [209.85.214.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-538-hi6mFCnFPBK2zG5MpZGrHg-1; Wed, 15 Dec 2021 11:55:07 -0500 X-MC-Unique: hi6mFCnFPBK2zG5MpZGrHg-1 Received: by mail-pl1-f197.google.com with SMTP id l14-20020a170903120e00b00143cc292bc3so6737401plh.1 for <52516-close@debbugs.gnu.org>; Wed, 15 Dec 2021 08:55:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=olJ1bjuaP/bGradBusCR8c4pRohjYe4MbJ+kz62XFPw=; b=TzhGGoC8017HO+wfQl/KKX89dZpzp4bFEedb2SH+Y9QCsdNo/aS+fB+jsNIgYGi/wX AVxurRkthlg1njRXpPknZbpvoxUX281ueT9TEk7a10dGqu9qi8YJ5TVbqELtqV6hDpBw z1rszC6yOA9s0XQlXe9w3CEc/r6+i0m06XJSTJLHmPdjxV+WNQWa9cLgRn6dnanz5uKP AhWkcUk+gsPaNIfvDeyhNZQAQCd/BXehQpt9TnIDloe6abvWnvIXSi5Fs0sXwYTREGi/ XnujiZmpcht+shsVtceULfbYJPsBE8718dMBjgm3mBhhM+83AccxcyUbyFgLztzdnp6p 2Dcg== X-Gm-Message-State: AOAM531l81uArPfGqNPuGst1PnT05aPUwT0KMsbeN7hiA5TOxb51d/kt t8TnYs40AfS/TVF8pWvQ66Jm+QkYNpeUpEx6Gv9B+aHjv/OePVenGgnGE8VA6Db4TlZXnOowXfY XWn9N16u/JSSFZ4O6SrV2MW3YA5QDJ9W6GX7MFfAqS/upPivEBan9nw2kGz1JkSTgYtLC X-Received: by 2002:a62:ee02:0:b0:4b1:3d41:450 with SMTP id e2-20020a62ee02000000b004b13d410450mr9830413pfi.8.1639587304215; Wed, 15 Dec 2021 08:55:04 -0800 (PST) X-Google-Smtp-Source: ABdhPJz9osKmxVi6S67oouDxVGHNZuSUShuOiFYYpxd75Iivb0kLlRhboMvqSuKtMlO/APGC3JXcAw== X-Received: by 2002:a62:ee02:0:b0:4b1:3d41:450 with SMTP id e2-20020a62ee02000000b004b13d410450mr9830390pfi.8.1639587303765; Wed, 15 Dec 2021 08:55:03 -0800 (PST) Received: from ohop.brianlane.com (c-73-157-26-10.hsd1.wa.comcast.net. [73.157.26.10]) by smtp.gmail.com with ESMTPSA id 66sm2864367pga.4.2021.12.15.08.55.00 for <52516-close@debbugs.gnu.org> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Dec 2021 08:55:01 -0800 (PST) Date: Wed, 15 Dec 2021 08:54:50 -0800 From: "Brian C. Lane" To: 52516-close@debbugs.gnu.org Subject: Re: bug#52516: Avoiding race condition between partprobe and getting PARTUUID using lsblk? Message-ID: References: MIME-Version: 1.0 In-Reply-To: Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=bcl@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 52516-close X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On Wed, Dec 15, 2021 at 01:12:43PM +0000, Anton Hvornum wrote: [snip] > My question boils down to: > 1. Is there a way to get an indication of when the partprobe (or > kernel) has completed its task of populating the partition > information? udevadm settle should help. The problem is that partprobe tells the kernel about all the partitions, the kernel then tells udev about the changes and then udev updates device nodes. So you cannot depend on anything being stable until udev is finished. > 2. Is there a way to tell partprobe/kernel to not clear the old > struct before the new information is available (leaving "old > information" intact until new exists, rather than wiping it and then > populating) No. It has to refresh everything, otherwise some parts of it might get out of sync. > If none of the two above is possible, I would like to consider those > being a feature as it would greatly help to verify when disk > operations are 100% complete. I don't mind optionally hanging > applications/scripts until parted is complete, as I would like to > avoid continuing based on parted exit code if the exit code is not a > guarantee of the process being completed in this case. There's not much you can do other than wait for udev, or check to make sure device nodes you expect to be present are there. We used to hit problems like this in the parted test suite all the time, until we added loops to wait for the partitions to appear. Good Luck! Brian -- Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart ------------=_1639587363-3571-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 15 Dec 2021 15:58:15 +0000 Received: from localhost ([127.0.0.1]:33550 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mxWfW-0005dK-8Z for submit@debbugs.gnu.org; Wed, 15 Dec 2021 10:58:15 -0500 Received: from lists.gnu.org ([209.51.188.17]:43384) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mxU6t-0007BG-Ll for submit@debbugs.gnu.org; Wed, 15 Dec 2021 08:14:20 -0500 Received: from eggs.gnu.org ([209.51.188.92]:58776) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mxU6s-0008Ms-AB for bug-parted@gnu.org; Wed, 15 Dec 2021 08:14:19 -0500 Received: from smtpout-55.fbg1.glesys.net ([185.39.145.55]:63666) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mxU6q-0001Bq-0X for bug-parted@gnu.org; Wed, 15 Dec 2021 08:14:17 -0500 X-Sender-ID: b6e48cdc-5da8-11ec-ad1a-2d7ca687e8f6 X-Gm-Message-State: AOAM530ud7LxrPlE8OI+x1qAotkY81Xrt7VihL06SOjwIF9oV6IZ1WRV eZsZqFgWh8j1hjcMJWurvOQJq9ElhKHZmUbX6hE= X-Google-Smtp-Source: ABdhPJyFyfFiNpdNdBIy2ItJZ8p+7yKDLs2YANZuNzoyEIXg7VRp9Lw1whi5ADkrgJwpHIvWjiSwyUPbGXF6Cv/jGoI= X-Received: by 2002:a05:6214:d0e:: with SMTP id 14mr11028604qvh.10.1639573974024; Wed, 15 Dec 2021 05:12:54 -0800 (PST) MIME-Version: 1.0 From: Anton Hvornum Date: Wed, 15 Dec 2021 13:12:43 +0000 X-Gmail-Original-Message-ID: Message-ID: Subject: Avoiding race condition between partprobe and getting PARTUUID using lsblk? To: bug-parted@gnu.org Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=185.39.145.55; envelope-from=anton@hvornum.se; helo=smtpout-55.fbg1.glesys.net X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Wed, 15 Dec 2021 10:58:13 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) Hi. So I've been struggling a bit with optimizing applications calling partprobe right after lsblk to retrieve PARTUUID of newly generated partitions using parted. Assuming the following loop: * partprobe * lsblk * if !result: sleep + loop It feels as if every partprobe (indirectly or directly) flushes a cache/struct of information somewhere, which makes lsblk "fail" to retrieve certain information if executed too quickly in succession. A normal approach to solving this is adding a delay between partprobe and lsblk, something I wanted to avoid by putting the sleep at the very end of the loop, and instead do many quick loops until the information is available. I could also put partprobe before the loop, and continue looping until the information becomes available. But that poses an issue if the disk-operation (parted) completes after partprobe performs it's tasks. Leaving the loop in a dead state until a new partprobe is called (or that seems to be the issue at least). My question boils down to: 1. Is there a way to get an indication of when the partprobe (or kernel) has completed its task of populating the partition information? 2. Is there a way to tell partprobe/kernel to not clear the old struct before the new information is available (leaving "old information" intact until new exists, rather than wiping it and then populating) If none of the two above is possible, I would like to consider those being a feature as it would greatly help to verify when disk operations are 100% complete. I don't mind optionally hanging applications/scripts until parted is complete, as I would like to avoid continuing based on parted exit code if the exit code is not a guarantee of the process being completed in this case. Best wishes: Anton Hvornum ------------=_1639587363-3571-1--