Bug 1575331

Summary: debug in udev do not work with "udevadm control --log-priority=debug" command
Product: Red Hat Enterprise Linux 7 Reporter: Amey <abetkike>
Component: udevAssignee: Michal Sekletar <msekleta>
Status: CLOSED WORKSFORME QA Contact: qe-baseos-daemons
Severity: low Docs Contact:
Priority: unspecified    
Version: 7.4CC: udev-maint-list
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-10-26 12:29:02 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 Amey 2018-05-06 02:56:40 UTC 
Description of problem:
debug in udev do not work with "udevadm control --log-priority=debug" command


Version-Release number of selected component (if applicable):
python-pyudev-0.15-9.el7.noarch
systemd-219-42.el7_4.10.x86_64

How reproducible:
everytime when udev is set in debug mode

Steps to Reproduce:
execute below
1. udevadm control --log-priority=debug
2. udevadm control --reload
3. cat /var/log/messages

Actual results:
udev do not log in debug mode

Expected results:
udev should log in /var/log/messages with log priority = debug


Additional info:
Comment 3 Michal Sekletar 2018-10-26 12:29:02 UTC 
udevadm control --log-priority=debug actually enables debug mode. Try running udevadm trigger afterward and check the system log. You will see a ton of debug output from udev. Also, you will see a message "udevd message (RELOAD) received" in journal which is logged at debug level.

It is just that --reload doesn't really do what you'd expect. Udev reloads configuration lazily. It kills all worker processes and drops the config loaded from rules in the past, however, it doesn't reload all the rules immediately. It does that when next uevent is received in the future.

Btw, I was checking in journal to rule out the possibility of misconfigured rsyslog.