Bug 1282814 - udev events are reordered relative to kernel uevents
udev events are reordered relative to kernel uevents
Status: CLOSED INSUFFICIENT_DATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: systemd (Show other bugs)
7.2
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: systemd-maint
qe-baseos-daemons
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-11-17 09:10 EST by Marius Vollmer
Modified: 2016-02-02 09:09 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-02-02 09:09:57 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
udevadm monitor (19.71 KB, text/plain)
2015-11-17 09:10 EST, Marius Vollmer
no flags Details

  None (edit)
Description Marius Vollmer 2015-11-17 09:10:47 EST
Created attachment 1095496 [details]
udevadm monitor

Description of problem:

During the check-storage-mdraid test of Cockpit, a existing partition disappears from the knowledge of storaged.  A "udevadm trigger" or restart of storaged brings it back.

The reason seems to be that storaged receives a "remove" udev event for that partition and nothing after that.  The reason for _that_ seems to be that something reorders events so that a pair of "remove/add" kernel uevents arrives as a "add/remove" udev events at the application.

Attached is a "udev monitor" log for a run of check-storage-mdraid.  The test essentially 

 - creates a mdraid device
 - mucks around a bit with it
 - creates a gpt partition table on it with parted
 - creates a 20 MB partition on it with parted
 - creates a partition with parted that fills the rest of the device

At this point, storaged has received a "remove" event for the first partition.

Version-Release number of selected component (if applicable):
systemd-219-11.el7.x86_64

How reproducible:
Always with the exact images that I am using.  Very sporadically with other images.



Here is the interesting part of the log:

KERNEL[114.740468] change   /devices/virtual/block/md127 (block)
KERNEL[114.742033] add      /devices/virtual/block/md127/md127p1 (block)
UDEV  [114.745086] remove   /devices/virtual/block/md127/md127p1 (block)
KERNEL[114.762729] remove   /devices/virtual/block/md127/md127p1 (block)   <- kernel remove
KERNEL[114.762999] add      /devices/virtual/block/md127/md127p1 (block)   <- kernel add
KERNEL[114.763589] add      /devices/virtual/block/md127/md127p2 (block)
KERNEL[114.777821] change   /devices/virtual/block/md127 (block)
UDEV  [114.793438] change   /devices/virtual/block/md127 (block)
UDEV  [114.813974] add      /devices/virtual/block/md127/md127p1 (block)
UDEV  [114.819050] add      /devices/virtual/block/md127/md127p1 (block)   <- udev add
UDEV  [114.842078] remove   /devices/virtual/block/md127/md127p1 (block)   <- udev remove
UDEV  [114.849552] add      /devices/virtual/block/md127/md127p2 (block)
UDEV  [114.879320] change   /devices/virtual/block/md127 (block)
KERNEL[115.050059] change   /devices/virtual/block/md127/md127p2 (block)
Comment 2 Marius Vollmer 2015-11-18 05:00:44 EST
As I found out later, the virtual machine had some unexpected CPU and I/O load on it while this was happening (mkdumprd was running).
Comment 3 Harald Hoyer 2015-12-14 10:17:21 EST
Could you please run udevadm monitor with the "-p" flag, so that we can see the sequence numbers?
Comment 4 Marius Vollmer 2016-02-02 09:09:57 EST
This has last happened on 27 Nov 2015, so I guess it has been fixed by some update or other.

Note You need to log in before you can comment on or make changes to this bug.