> Linux-2.4.4 has a change, for which I must accept blame,
> where fork() runs the child first, reducing unnecessary copy-on-write
> page duplications, because the child will usually promptly do an
> exec(). I understand this is pretty standard in most unixes.
>
> Peter Osterlund noticed an annoying side effect of this,
> which I think is a bash bug. He wrote:
>
> > Another thing is that the bash loop "while true ; do /bin/true ; done" is
> > not possible to interrupt with ctrl-c.
>
> I have reproduced this problem on a single CPU system.
> I also modified my kernel to sometimes run the fork child first
> and sometimes not. In that case, that loop would sometimes
> abort on a control-C and sometimes ignore it, but ignoring it
> would not make the loop less likely to abort on another control-C.
> I'm pretty sure the control-C was being delivered only to the child
> due to a race condition in bash, which may be mandated by posix.
Did you reconfigure and rebuild bash on your machine running the 2.4
kernel, or just use a bash binary built on a previous kernel version?
Bash has an autoconf test that will, if it detects the need to do so,
force the job control code to synchronize between parent and child
when setting up the process group for a new pipeline. It may be the
case that you have to reconfigure and rebuild bash to enable that code.
Look for PGRP_PIPE in config.h.
-- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet)Chet Ramey, CWRU chet@po.CWRU.Edu http://cnswww.cns.cwru.edu/~chet/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Apr 30 2001 - 21:00:25 EST