Bug 1688316 - lvm tools expect access to udev, even when disabled in the configuration [rhel-7.6.z]
Summary: lvm tools expect access to udev, even when disabled in the configuration [rhe...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: lvm2
Version: 7.6
Hardware: x86_64
OS: Linux
urgent
urgent
Target Milestone: rc
: ---
Assignee: Marian Csontos
QA Contact: cluster-qe@redhat.com
URL:
Whiteboard:
: 1695732 (view as bug list)
Depends On: 1676612
Blocks: 1676466
TreeView+ depends on / blocked
 
Reported: 2019-03-13 14:24 UTC by RAD team bot copy to z-stream
Modified: 2019-07-12 04:18 UTC (History)
22 users (show)

Fixed In Version: lvm2-2.02.180-10.el7_6.4
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1676612
Environment:
Last Closed: 2019-04-23 14:28:11 UTC
Target Upstream Version:


Attachments (Terms of Use)
udev disabled in lvm.conf and lvm rpms installed (127.07 KB, text/plain)
2019-03-18 09:15 UTC, Saravanakumar
no flags Details
udev enabled and latest lvm rpms installed (126.99 KB, text/plain)
2019-03-18 09:20 UTC, Saravanakumar
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2019:0814 None None None 2019-04-23 14:28:15 UTC
Red Hat Bugzilla 1674475 None None None 2019-12-04 06:48:28 UTC
Red Hat Bugzilla 1675134 'urgent' 'CLOSED' '[GSS] Gluster pod loses udev access with 3.11.1 upgrade' 2019-12-04 06:48:28 UTC
Red Hat Bugzilla 1676466 'urgent' 'CLOSED' 'LVM in the glusterfs container should not try to use udev' 2019-12-04 06:48:28 UTC

Description RAD team bot copy to z-stream 2019-03-13 14:24:11 UTC
This bug has been copied from bug #1676612 and has been proposed to be backported to 7.6 z-stream (EUS).

Comment 3 Marian Csontos 2019-03-13 15:58:46 UTC
Looks like this will get SanityOnly testing from our QE, so a fix verification is up to OpenShift.

Niels, could you please try with 7.6.z scratch build before handing over to QE?

http://brew-task-repos.usersys.redhat.com/repos/scratch/mcsontos/lvm2/2.02.180/10.el7_6.3.bz1688316/lvm2-2.02.180-10.el7_6.3.bz1688316-scratch.repo

Scratch build for reference:

https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=20576533

Comment 4 Niels de Vos 2019-03-14 21:01:42 UTC
Hi Marian, I will not be available tomorrow and next week.

Saravana, could you try this out (and include the change for bug 1676466) in a scratch build? Stracing pvscan in the rhgs-server container should not show any open() or read() calls of /run/udev....something.

Comment 5 Saravanakumar 2019-03-18 09:15:47 UTC
Created attachment 1545147 [details]
udev disabled in lvm.conf and lvm rpms installed

(In reply to Niels de Vos from comment #4)
> Hi Marian, I will not be available tomorrow and next week.
> 
> Saravana, could you try this out (and include the change for bug 1676466) in
> a scratch build? Stracing pvscan in the rhgs-server container should not
> show any open() or read() calls of /run/udev....something.


I have made a scratch build with the rpms mentioned and disabled obtain_device_list_from_udev.

Refer without_udev.txt for:
1. rpms installed
2. udev disabled in /etc/lvm/lvm.conf
3. strace output.

I could still see access to /run/udev/control file.  Please check the attached file.

munmap(0x7f9cd8033000, 4096)            = 0
access("/run/udev/control", F_OK)       = -1 ENOENT (No such file or directory)
stat("/dev", {st_mode=S_IFDIR|0755, st_size=3460, ...}) = 0


PS:
1. There is NO corresponding rpm for device-mapper-persistent-data here. so using the existing one. (Refer the rpm output)
http://brew-task-repos.usersys.redhat.com/repos/scratch/mcsontos/lvm2/2.02.180/10.el7_6.3.bz1688316/x86_64/

2. I run the docker container as below - FYI.

docker run --privileged=true --net=host -v /etc/glusterfs:/etc/glusterfs:z -v /var/lib/glusterd:/var/lib/glusterd:z -v /var/log/glusterfs:/var/log/glusterfs:z -v /sys/fs/cgroup:/sys/fs/cgroup:ro  -v /dev:/dev -e TCMU_LOGDIR=/var/log/glusterfs/gluster-block -e GB_GLFS_LRU_COUNT=15  --name udev-disabled-gluster <image name>

Comment 6 Saravanakumar 2019-03-18 09:20:03 UTC
Created attachment 1545148 [details]
udev enabled and latest lvm rpms installed

For the sake of comparison, I have left obtain_device_list_from_udev as is (ie., enabled) and with latest lvm rpms installed, took strace output of pvscan in the attached.

Comment 7 Marian Csontos 2019-03-18 13:11:07 UTC
The original bug reports a slow down when running lvm operations, due to waiting for udev database:

> Description of problem:
> When running lvm commands (pvscan and the like) in a container, progress is really slow
> and can take many hours (depending on the number of devices and possibly other factors).
>
> While running 'pvs' messages like these are printed:
>
>  WARNING: Device /dev/xvda2 not initialized in udev database even after waiting 10000000 microseconds.
>  WARNING: Device /dev/xvdb1 not initialized in udev database even after waiting 10000000 microseconds.

I am not sure at all, if the mentioned udev/control access is safe, or something what needs to be further investigated. Peter, you might know more about this...

Are the activation/udev_sync and activation/udev_rules configuration options set?

Comment 8 Peter Rajnoha 2019-03-18 13:41:53 UTC
(In reply to Marian Csontos from comment #7)
> 
> I am not sure at all, if the mentioned udev/control access is safe, or
> something what needs to be further investigated. Peter, you might know more
> about this...
> 

That's OK and expected - that part comes from libudev initialization actually. We're using libudev at libdm initialization (which in turn is used by LVM tools) to collect information about system's environment and see if udev is available and check this once per whole LVM tool execution.

The activation/udev_sync, activation/udev_rules and devices/obtain_device_list_from_udev doesn't have effect on whether we use libudev or not. We're still using libudev in all cases to check system's environment and udev's state. This is because you can override lvm.conf settings via --config and/or you can run lvm commands in LVM shell where you can define that --config for each command setting various udev behaviour. So we check for global udev state once to not repeat that uselessly. Anyway, this part is not a problem (doesn't cause any hangs or so).

Comment 9 Marian Csontos 2019-03-18 14:34:28 UTC
However, I do not see any access to udev database in either of then log files.

Checked the code, and not only the settings have no effect on whether we initialize the udev, but vice versa, when udev is not available, the above settings have no effect and udev shall not be used.

Previously the two udev calls were unconditional. Now the problematic udev DB access is properly using conditional `obtain_device_list_from_udev` which is initialised to 0 when `udev_is_running()` fails (and in other cases).

I am preparing a 7.6.z errata. Thanks

Comment 12 Matt Flusche 2019-04-16 16:03:52 UTC
*** Bug 1695732 has been marked as a duplicate of this bug. ***

Comment 16 errata-xmlrpc 2019-04-23 14:28:11 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:0814


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