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.
DescriptionMichele Baldessari
2020-03-24 11:36:15 UTC
Description of problem:
Can we please include the upstream commit http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=48755ebf093543113de96747a7f5f78e0640b333 (and the dependent factor out one 0541a1adf7c25356e7bbd792a8d6ee217a0d92f3) so that we do not call close() on "max_fd = sysconf(_SC_OPEN_MAX);" which can be quite high depending on host or container (max fd) where it is being run?
Asking because it quite affects startup performance when a container has a largish 1M fds:
A) Pristine rhel-8.2 dnsmasq-2.79-11.el8.x86_64
19 11:26:49.414861 execve("/sbin/dnsmasq", ["/sbin/dnsmasq", "--conf-file=/etc/ironic-inspector/dnsmasq.conf", "-k", "--log-facility=/var/log/ironic-inspector/dnsmasq.log"], 0x7fffd9e40bc8 /* 15 vars */) = 0
...
19 11:26:49.436593 close(6) = -1 EBADF (Bad file descriptor)
...
19 11:27:20.776605 close(1048575) = -1 EBADF (Bad file descriptor)
...
19 11:27:20.793024 poll([{fd=4<socket:[2140744]>, events=POLLIN}, {fd=5<socket:[2140745]>, events=POLLIN}, {fd=6<anon_inode:inotify>, events=POLLIN}, {fd=7<pipe:[2140751]>, events=POLLIN}], 4, -1
B) dnsmasq-2.79-11.0.noclose.0.el8.x86_64 which has two patches applied:
- 0541a1adf7c25356e7bbd792a8d6ee217a0d92f3 Factor out closing all file descriptors for later
- 48755ebf093543113de96747a7f5f78e0640b333 Optimise closing file descriptors.
18 11:29:47.527284 execve("/sbin/dnsmasq", ["/sbin/dnsmasq", "--conf-file=/etc/ironic-inspector/dnsmasq.conf", "-k", "--log-facility=/var/log/ironic-inspector/dnsmasq.log"], 0x7ffe5dbac1e8 /* 15 vars */) = 0
...
18 11:29:47.553800 poll([{fd=4<socket:[2176572]>, events=POLLIN}, {fd=5<socket:[2176573]>, events=POLLIN}, {fd=6<anon_inode:inotify>, events=POLLIN}, {fd=7<pipe:[2176579]>, events=POLLIN}], 4, -1
Now tests were run under strace so clearly exacerbated the slowness of case A), but the point still remains.
We're trying to hunt down all these unneeded close() calls all over OSP (e.g. https://bugzilla.redhat.com/show_bug.cgi?id=1762025, https://github.com/erlang/otp/pull/2438, https://bugzilla.redhat.com/show_bug.cgi?id=1762794 ) and it would be nice if we applied those two upstream commits from dnsmasq as well.
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 (dnsmasq bug fix and enhancement update), 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-2020:4673