Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1141690

Summary: Leftover dangling symlinks in /dev after device removal
Product: Red Hat Enterprise Linux 6 Reporter: Peter Rajnoha <prajnoha>
Component: udevAssignee: Harald Hoyer <harald>
Status: CLOSED INSUFFICIENT_DATA QA Contact: qe-baseos-daemons
Severity: medium Docs Contact:
Priority: medium    
Version: 6.6CC: agk, cww, jnikolak, prajnoha, udev-maint-list, zkabelac
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-11-10 15:16:10 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:
Bug Depends On:    
Bug Blocks: 1172231    
Attachments:
Description Flags
udevadm and udevd logs none

Description Peter Rajnoha 2014-09-15 09:10:18 UTC
Created attachment 937487 [details]
udevadm and udevd logs

(This is probably another incarnation of 749178, however, this time found in RHEL6)

I can reproduce this in 100% of cases in this exact scenario (snapshot of raid1 LV):

[root@rhel6-b ~]# vgcreate vg /dev/sd[a-p]
  Clustered volume group "vg" successfully created
[root@rhel6-b ~]# lvcreate -l1 -m1 --type raid1 vg
  Logical volume "lvol0" created
[root@rhel6-b ~]# lvcreate -l1 -s vg/lvol0
  Logical volume "lvol1" created
[root@rhel6-b ~]# vgchange -an vg
  0 logical volume(s) in volume group "vg" now active

The logs from udevadm monitor and udev daemon are attached (grabbed during the vgchange -an vg call from the reproducer above). The device for which there was symlink left unremoved was dm-7:

[root@rhel6-b ~]# ls -l /dev/vg
total 0
lrwxrwxrwx. 1 root root 7 Sep 15 10:58 lvol1 -> ../dm-7

[root@rhel6-b ~]# ls -l /dev/dm-7
ls: cannot access /dev/dm-7: No such file or directory

Reproduced with:

[root@rhel6-b ~]# rpm -q kernel lvm2 udev
kernel-2.6.32-502.el6.x86_64
lvm2-2.02.111-2.1.el6.x86_64
udev-147-2.57.el6.x86_64

Comment 1 Harald Hoyer 2014-10-22 13:06:27 UTC
So, dm-7 also claims to be lvol1.

1410771495.765203 [6664] link_find_prioritized: '/sys/devices/virtual/block/dm-7' claims priority 0 for '/dev/.udev/links/mapper\x2fvg-lvol1'
1410771495.765212 [6664] link_update: creating link '/dev/mapper/vg-lvol1' to '/dev/dm-7'
1410771495.765222 [6664] node_symlink: preserve already existing symlink '/dev/mapper/vg-lvol1' to '../dm-7'
1410771495.765471 [6664] link_find_prioritized: found '/sys/devices/virtual/block/dm-7' claiming '/dev/.udev/links/vg\x2flvol1'
1410771495.765483 [6664] udev_device_new_from_syspath: device 0x7f7995f211c0 has devpath '/devices/virtual/block/dm-7'
1410771495.765535 [6664] udev_device_read_db: device 0x7f7995f211c0 filled with db file data
1410771495.765541 [6664] link_find_prioritized: '/sys/devices/virtual/block/dm-7' claims priority 0 for '/dev/.udev/links/vg\x2flvol1'
1410771495.765549 [6664] link_update: creating link '/dev/vg/lvol1' to '/dev/dm-7'
1410771495.765558 [6664] node_symlink: preserve already existing symlink '/dev/vg/lvol1' to '../dm-7'
1410771495.765614 [6664] link_find_prioritized: found '/sys/devices/virtual/block/dm-7' claiming '/dev/.udev/links/disk\x2fby-id\x2fdm-name-vg-lvol1'


... In the udev log I cannot find anything about dm-7.

monitor logs:

UDEV  [1410771495.790431] remove   /devices/virtual/block/dm-7 (block)
DEVLINKS=/dev/mapper/vg-lvol0-real /dev/block/253:7

Comment 2 Harald Hoyer 2014-11-20 13:53:33 UTC
(In reply to Harald Hoyer from comment #1)
> So, dm-7 also claims to be lvol1.
> 
> 1410771495.765203 [6664] link_find_prioritized:
> '/sys/devices/virtual/block/dm-7' claims priority 0 for
> '/dev/.udev/links/mapper\x2fvg-lvol1'
> 1410771495.765212 [6664] link_update: creating link '/dev/mapper/vg-lvol1'
> to '/dev/dm-7'
> 1410771495.765222 [6664] node_symlink: preserve already existing symlink
> '/dev/mapper/vg-lvol1' to '../dm-7'
> 1410771495.765471 [6664] link_find_prioritized: found
> '/sys/devices/virtual/block/dm-7' claiming '/dev/.udev/links/vg\x2flvol1'
> 1410771495.765483 [6664] udev_device_new_from_syspath: device 0x7f7995f211c0
> has devpath '/devices/virtual/block/dm-7'
> 1410771495.765535 [6664] udev_device_read_db: device 0x7f7995f211c0 filled
> with db file data
> 1410771495.765541 [6664] link_find_prioritized:
> '/sys/devices/virtual/block/dm-7' claims priority 0 for
> '/dev/.udev/links/vg\x2flvol1'
> 1410771495.765549 [6664] link_update: creating link '/dev/vg/lvol1' to
> '/dev/dm-7'
> 1410771495.765558 [6664] node_symlink: preserve already existing symlink
> '/dev/vg/lvol1' to '../dm-7'
> 1410771495.765614 [6664] link_find_prioritized: found
> '/sys/devices/virtual/block/dm-7' claiming
> '/dev/.udev/links/disk\x2fby-id\x2fdm-name-vg-lvol1'
> 
> 
> ... In the udev log I cannot find anything about dm-7.
> 
> monitor logs:
> 
> UDEV  [1410771495.790431] remove   /devices/virtual/block/dm-7 (block)
> DEVLINKS=/dev/mapper/vg-lvol0-real /dev/block/253:7

I miss the logs from the dm-7 ADD/CHANGE uevent

Comment 3 Harald Hoyer 2015-10-13 09:14:29 UTC
still need some info

Comment 4 Peter Rajnoha 2015-10-14 07:49:31 UTC
*** Bug 1178067 has been marked as a duplicate of this bug. ***

Comment 6 Zdenek Kabelac 2015-11-13 12:48:00 UTC
FYI  lvm2 knows about one individual case where we've put into a single 'udev transaction' activation and deactivation of a single volume during snapshot manipulation - and this caused racy behaviour in udev (e.g. node disappeared while udev process 'add' event)

It appears the latest versions of udev are 'fixed' for this case - for older version we may eventually resequence activation code to spread steps into multiple transaction points - not seeing this as urgent issue - so it may or may not happen anytime soon.