Bug 1217238 - ksh misbehavior if login shell "( cmd & )" does nothing and no error reported
Summary: ksh misbehavior if login shell "( cmd & )" does nothing and no error reported
Alias: None
Product: Fedora
Classification: Fedora
Component: ksh
Version: 23
Hardware: All
OS: All
Target Milestone: ---
Assignee: Michal Hlavinka
QA Contact: Fedora Extras Quality Assurance
Depends On: 1217236
Blocks: 1217237
TreeView+ depends on / blocked
Reported: 2015-04-29 20:30 UTC by Paulo Andrade
Modified: 2019-10-10 09:47 UTC (History)
2 users (show)

Fixed In Version: ksh-20120801-28.fc24
Doc Type: Bug Fix
Doc Text:
Clone Of: 1217236
Last Closed: 2015-08-28 11:02:15 UTC
Type: Bug

Attachments (Terms of Use)

Description Paulo Andrade 2015-04-29 20:30:36 UTC
+++ This bug was initially created as a clone of Bug #1217236 +++

To test, either have ksh as login shell, or create a test user.
Then ssh localhost.

Sample session:

$ cd /tmp/alan
$ cat tst.ksh

echo $D > /tmp/alan/tst.dat

$ ls
$ (ksh /tmp/alan/tst.ksh &)
[1]	28190
$ ls

This happens due to a double fork, once for "( cmd )" and
then the first fork forks again due to the "&", but, just
when the child branches, it receives a SIGHUP and
immediately exits.

I tested a quick&dirty patch, that basically reverts to
rhel5 ksh behavior, and there are no regressions in the
test cases.

diff -up ksh-20120801/src/cmd/ksh93/sh/xec.c.orig ksh-20120801/src/cmd/ksh93/sh/xec.c
--- ksh-20120801/src/cmd/ksh93/sh/xec.c.orig	2015-04-28 16:55:25.521818636 -0300
+++ ksh-20120801/src/cmd/ksh93/sh/xec.c	2015-04-28 16:56:34.037753565 -0300
@@ -2059,16 +2059,20 @@ int sh_exec(register const Shnode_t *t,
 			else if(((type=t->par.partre->tre.tretyp)&FAMP) && ((type&COMMSK)==TFORK))
+#if 0
 				pid_t	pid;
 				while((pid=fork())< 0)
+#if 0

I also asked upstream, see http://lists.research.att.com/pipermail/ast-users/2015q2/004754.html
but actually, there is a bad comment there, about crashes if
running it as "( cmd ) &". Likely it was due to the way I was
debugging it.

Note that if one has bash as login shell, then starts, or exec
ksh, or even if has ksh as login shell, and first exec ksh,
it will work, because then SIGHUP will be blocked in the
"orphan" process (orphan due to double fork).

Comment 1 Paulo Andrade 2015-04-29 20:31:17 UTC
Reported for rawhide, but happens in all non EOL
Fedora releases.

Comment 2 Jan Kurik 2015-07-15 14:13:22 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle.
Changing version to '23'.

(As we did not run this process for some time, it could affect also pre-Fedora 23 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.)

More information and reason for this action is here:

Comment 3 Michal Hlavinka 2015-08-24 17:01:48 UTC
This bug is a regression of a fix that upstream made:

10-09-21  A bug in the processing of (command&) which created a job in the
	  parent process has been fixed.

and exactly the commented-out code was added as the fix (original code also did a backup and restoration of sh.bckpid around sh_exec. So we can't just revert that change.

Comment 5 Michal Hlavinka 2015-08-28 11:02:15 UTC
Fixed in

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