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 1318646 - [RFE] Show actual running udev max-childs parameter
Summary: [RFE] Show actual running udev max-childs parameter
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: udev
Version: 6.9
Hardware: All
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Michal Sekletar
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks: 1269194 1356047
TreeView+ depends on / blocked
 
Reported: 2016-03-17 12:39 UTC by Stefan Meyer
Modified: 2019-10-10 11:35 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
: 1361601 (view as bug list)
Environment:
All RHEL versions
Last Closed: 2016-07-29 13:32:21 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Stefan Meyer 2016-03-17 12:39:12 UTC
Description of problem:
When overriding the parameters for 

RHEL 5: udevcontrol max_childs=X
RHEL 6: udevadm control --max-childs=X
RHEL 7: udevadm control --children-max=X

either on the command line or via kernel boot parameters there is no way 
to show the currently configured value once the system is fully booted.

Version-Release number of selected component (if applicable):
RHEL 5, 6 and 7

How reproducible:
Always

Steps to Reproduce:
RHEL 5: # udevcontrol max_childs=7
RHEL 6: # udevadm control --max-childs=7
RHEL 7: # udevadm control --children-max=7

There is no way to read the currently set value.


Actual results:
No command option available to show the actual used value.

Expected results:
Create a command option for udevcontrol/udevadm to show the running configuration.

As an alternative:
Make the information available in /proc/<process_id>

As the preferred option:
Make the actual configured udev timeout parameter visible.

Additional info:

Comment 3 Michal Sekletar 2016-07-22 07:20:40 UTC
udevadm and udevd interaction is only one directional, meaning that udevadm only sends control command to udev daemon, but no data is returned back from the daemon to client.

For now I've implemented change that introduces new option for udevadm control and udevd upon receiving new type of control message logs current value of children_max parameter on INFO log level, hence message is by default visible in system log. 

Would above solution satisfy this RFE?

Comment 4 Stefan Meyer 2016-07-22 07:35:58 UTC
That solution would not satisfy the RFE as logs are purged automatically and the control messages with it.

Comment 5 Michal Sekletar 2016-07-29 13:29:08 UTC
(In reply to Stefan Meyer from comment #4)
> That solution would not satisfy the RFE as logs are purged automatically and
> the control messages with it.

I've reworked my initial implementation and proposed it upstream, but PR was rejected. However, we will address this issue upstream, but approach will be very different from my solution. Unfortunately, it won't be possible to backport new fix to RHEL6. I will clone this bug for RHEL7 and close this one.

https://github.com/systemd/systemd/pull/3808


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