Hide Forgot
* multipathd crashed with a status of with a "multipathd dead but pid file exists" when multipath was configured for 1024 or more paths, because it was unable to open a file descriptor for each path. This may also have caused "error calling out /sbin/mpath_prio_ontap /dev/[device]" errors. Now, a new multipath.conf parameter, "max_fds", allows end-users to set the maximum number of file descriptors that the multipathd process can have open, or to use "max" to set the number to the system maximum. Setting max_fds to either a sufficiently high number or to "max" avoids this crash in multipathd.
+++ This bug was initially created as a clone of Bug #457226 +++ Description of problem: On a RHEL4.7 host, I have 256 luns mapped each with 4 FCP paths giving a total of 1024 paths. The FCP HBA driver on the host properly detects all these paths i.e. all 1024 entries are present in the sysfs. But when I start multipathd with the option max_fds set to "unlimited" in multipath.conf file, the daemon fails to start up: # /etc/init.d/multipathd start Starting multipathd daemon: [ OK ] # /etc/init.d/multipathd status multipathd dead but pid file exists I see the following message in /var/log/messages -- multipathd: can't set open fds limit to -1 : Operation not permitted Version-Release number of selected component (if applicable): # rpm -qa | grep device device-mapper-event-1.02.24-1.el5 device-mapper-1.02.24-1.el5 device-mapper-1.02.24-1.el5 device-mapper-multipath-0.4.7-17.el5 How reproducible: Always Steps to Reproduce: 1. Map 256 luns to a RHEL4.7 host with 4 FCP paths each thereby giving a total of 1024 paths. 2. Add the option "max_fds unlimited" in defaults section in multipath.conf file. 3. Configure maps for all the devices, by running "multipath -v3" command. 4. Start the multipathd daemon. Actual results: The multipathd daemon gets killed during startup for the above setup. # /etc/init.d/multipathd status multipathd dead but pid file exists Expected results: The multipathd daemon should start properly, with fd limit set to a possible maximum value. Additional info: 1. If max_fds option is configured with a sufficiently high numerical value, multipathd starts up fine. 2. /etc/multipath.conf settings are attached. -- Additional comment from rajashekhar.a@netapp.com on 2008-07-30 08:24 EST -- Created an attachment (id=312991) multipath.conf settings
Added New Release Notes Contents.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
The fix was backported from RHEL5. multipath.conf no longer allows the "unlimited " option, since the linux kernel does not allow processes to open unlimited file descriptors. Instead, you can use the "max" option for max_fds. This sets the number of fds to the maximum allowable.
Release note updated. If any revisions are required, please set the "requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1,3 +1 @@ -In /etc/multipath.conf, setting max_fds to unlimited will prevent the multipathd +* multipathd crashed with a status of with a "multipathd dead but pid file exists" when multipath was configured for 1024 or more paths, because it was unable to open a file descriptor for each path. This may also have caused "error calling out /sbin/mpath_prio_ontap /dev/[device]" errors. Now, a new multipath.conf parameter, "max_fds", allows end-users to set the maximum number of file descriptors that the multipathd process can have open, or to use "max" to set the number to the system maximum. Setting max_fds to either a sufficiently high number or to "max" avoids this crash in multipathd.-daemon from starting up properly. As such, you should use a sufficiently high -value instead for this setting.
~~ Attention Partners! ~~ RHEL 4.8 Partner Alpha has been released on partners.redhat.com. There should be a fix present in the Beta, which addresses this bug. If you have already completed testing your other URGENT priority bugs, and you still haven't had a chance yet to test this bug, please do so at your earliest convenience, to ensure that only the highest possible quality bits are shipped in the upcoming public Beta drop. If you encounter any issues, please set the bug back to the ASSIGNED state and describe the issues you encountered. Further questions can be directed to your Red Hat Partner Manager. Thanks, more information about Beta testing to come. - Red Hat QE Partner Management
I have verified this issue in RHEL4.8 alpha and this is fixed.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2009-1011.html