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.
Description of problem:
Version-Release number of selected component (if applicable):
ksh-20100621-12.el6_2.1.x86_64
How reproducible:
Always
Steps to Reproduce:
1. su -
2. ksh
3. A=${pvs)
Actual results:
File descriptor 11 (/tmp/sf3e.p59 (deleted)) leaked on pvs invocation. Parent PID 22694: ksh
Expected results:
(no warnings)
Additional info:
This is not reproducible on RHEL5.7
So far I have only reproduced it using execution of the LVM command through a variable assignment as per the syntax above.
Further analysis of an strace shows the following ...
ksh on rhel57 (ksh-20100202-1.el5_6.6) does the following, dupping FD#10 to FD#1 and then closing FD#10 after a clone of pid 13008.
13007 fstat(1, {st_mode=S_IFSOCK|0200, st_size=0, ...}) = 0
13007 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x2b1db3dcefe0) = 13008
13007 fstat(5, {st_mode=S_IFSOCK|0400, st_size=0, ...}) = 0
13007 fstat(5, {st_mode=S_IFSOCK|0400, st_size=0, ...}) = 0
13007 close(1) = 0
13007 close(1) = -1 EBADF (Bad file descriptor)
13007 fcntl(10, F_DUPFD, 1) = 1
13007 close(10) = 0
but ksh on rhel61 (ksh-20100621-6.el6.x86_64) does the following, dupping FD#1 to FD#11 then forking and dupping FD#11 to FD#1 and closing FD#11 after the fork.
10957 rt_sigprocmask(SIG_BLOCK, [HUP INT QUIT PIPE], [], 8) = 0
10957 vfork() = 10964
10957 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
10964 rt_sigprocmask(SIG_SETMASK, [], <unfinished ...>
10957 close(1 <unfinished ...>
10964 <... rt_sigprocmask resumed> NULL, 8) = 0
10957 <... close resumed> ) = 0
10957 fcntl(11, F_DUPFD, 1) = 1
10964 execve("/sbin/lvs", ["lvs"], [/* 31 vars */] <unfinished ...>
10957 close(11) = 0
So it looks like because RHEL5.7 uses clone, we are able to close FD#10 after a clone because
"Unlike fork(2), these calls allow the child process to share parts of its execution
context with the calling process, such as the memory space, the table of file
descriptors, and the table of signal handlers."
but because RHEL6.1 uses vfork we cannot close FD#11 after the fork.
So this looks like a bug introduced in the new version of ksh.
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.
http://rhn.redhat.com/errata/RHBA-2012-0952.html
Description of problem: Version-Release number of selected component (if applicable): ksh-20100621-12.el6_2.1.x86_64 How reproducible: Always Steps to Reproduce: 1. su - 2. ksh 3. A=${pvs) Actual results: File descriptor 11 (/tmp/sf3e.p59 (deleted)) leaked on pvs invocation. Parent PID 22694: ksh Expected results: (no warnings) Additional info: This is not reproducible on RHEL5.7 So far I have only reproduced it using execution of the LVM command through a variable assignment as per the syntax above. Further analysis of an strace shows the following ... ksh on rhel57 (ksh-20100202-1.el5_6.6) does the following, dupping FD#10 to FD#1 and then closing FD#10 after a clone of pid 13008. 13007 fstat(1, {st_mode=S_IFSOCK|0200, st_size=0, ...}) = 0 13007 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x2b1db3dcefe0) = 13008 13007 fstat(5, {st_mode=S_IFSOCK|0400, st_size=0, ...}) = 0 13007 fstat(5, {st_mode=S_IFSOCK|0400, st_size=0, ...}) = 0 13007 close(1) = 0 13007 close(1) = -1 EBADF (Bad file descriptor) 13007 fcntl(10, F_DUPFD, 1) = 1 13007 close(10) = 0 but ksh on rhel61 (ksh-20100621-6.el6.x86_64) does the following, dupping FD#1 to FD#11 then forking and dupping FD#11 to FD#1 and closing FD#11 after the fork. 10957 rt_sigprocmask(SIG_BLOCK, [HUP INT QUIT PIPE], [], 8) = 0 10957 vfork() = 10964 10957 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 10964 rt_sigprocmask(SIG_SETMASK, [], <unfinished ...> 10957 close(1 <unfinished ...> 10964 <... rt_sigprocmask resumed> NULL, 8) = 0 10957 <... close resumed> ) = 0 10957 fcntl(11, F_DUPFD, 1) = 1 10964 execve("/sbin/lvs", ["lvs"], [/* 31 vars */] <unfinished ...> 10957 close(11) = 0 So it looks like because RHEL5.7 uses clone, we are able to close FD#10 after a clone because "Unlike fork(2), these calls allow the child process to share parts of its execution context with the calling process, such as the memory space, the table of file descriptors, and the table of signal handlers." but because RHEL6.1 uses vfork we cannot close FD#11 after the fork. So this looks like a bug introduced in the new version of ksh.