Bug 1283112

Summary: parted races with systemd-udevd
Product: Red Hat Enterprise Linux 7 Reporter: Marius Vollmer <mvollmer>
Component: partedAssignee: Brian Lane <bcl>
Status: CLOSED DUPLICATE QA Contact: Release Test Team <release-test-team-automation>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.2CC: bcl, nkshirsa, stefw
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-11-18 20:39:37 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Marius Vollmer 2015-11-18 09:56:37 UTC 
Description of problem:

See https://github.com/cockpit-project/cockpit/issues/3177

Both parted and systemd-udevd tell the kernel about new partitions, and if circumstances are right, parted fails with an error message because it tries to tell the kernel about a partition that it already knows about.

This has probably been addressed in some way already, since I don't see this with parted 3.2.

Version-Release number of selected component (if applicable):
parted-3.1-22.el7.x86_64

How reproducible:
'Always' when the circumstances are right, but very seldom normally.  Loading the system to about 100% CPU with "while true; do true; done" did the trick for me. 

Tell me if you want to reproduce this.
Comment 2 Marius Vollmer 2015-11-18 12:40:30 UTC 
*** Bug 1283128 has been marked as a duplicate of this bug. ***
Comment 3 Brian Lane 2015-11-18 20:39:37 UTC 
This is 'fixed' in 3.1-23 by changing parted so that it will probe using read only, and only close the r/w file descriptor when finished running.

Note that if you are calling parted multiple times from a script and not checking for device nodes to appear/disappear/whatever you will end up in the same situation. It is best to combine all the commands into a single parted call, or check for the expected changes between the calls.

*** This bug has been marked as a duplicate of bug 1245144 ***