Bug 102042

Summary:	process stops when backgrounding
Product:	[Fedora] Fedora	Reporter:	Michael Redinger <michael.redinger>
Component:	zsh	Assignee:	Jens Petersen <petersen>
Status:	CLOSED RAWHIDE	QA Contact:	Mike McLean <mikem>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	1	CC:	roland
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2004-01-13 06:25:46 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Michael Redinger 2003-08-09 15:54:24 UTC

I found a strange problem when recompiling some SRPMs:
When backgrounding rpmbuild, it gets stopped at some point. If you put the 
job in the foreground, it continues running correctly (however, job control 
does not seem to work correctly then - after stopping the build process 
with Strg-C, building continues until I have killed the processes).

I saw this when rebuilding zsh-4.0.7-1.src.rpm and 
coreutils-4.5.3-22.src.rpm.

This is 100% reproduceable for me (the zsh and coreutils rebuild always 
hangs at the same point.)

zsh:
$ rpmbuild --rebuild zsh-4.0.7-1.src.rpm &
...
checking if link() works... yes
checking if kill(pid, 0) returns ESRCH correctly... yes
checking if POSIX sigsuspend() works... yes
checking if tcsetpgrp() actually works...

Here the process hangs. If I hit enter now:
[1]+  Stopped                 rpmbuild --rebuild zsh-4.0.7-1.src.rpm

Now forgrounding it:
$ fg

... everything continues correctly


If I attach strace to the hanging/stopped process, I get the following:

--- SIGSTOP (Stopped (signal)) @ 0 (0) ---
--- SIGSTOP (Stopped (signal)) @ 0 (0) ---
ioctl(0, TIOCSPGRP, [1387])             = ? ERESTARTSYS (To be restarted)
--- SIGTTOU (Stopped (tty output)) @ 0 (0) ---
--- SIGTTOU (Stopped (tty output)) @ 0 (0) ---
ioctl(0, TIOCSPGRP, [1387])             = ? ERESTARTSYS (To be restarted)
--- SIGTTOU (Stopped (tty output)) @ 0 (0) ---
--- SIGTTOU (Stopped (tty output)) @ 0 (0) ---
ioctl(0, TIOCSPGRP, [1387])             = ? ERESTARTSYS (To be restarted)
--- SIGTTOU (Stopped (tty output)) @ 0 (0) ---
--- SIGTTOU (Stopped (tty output)) @ 0 (0) ---

"TIOCSPGRP / SIGTTOU" continues infinitely 


This is on a Dell PowerEdge 2400 dual-cpu server, I am connected to the 
server using (Open)SSH.
I also tried the single processor kernel, same result.
I also tried to run it from the console, same problem.

Comment 1 Michael Redinger 2003-08-09 15:56:39 UTC

*** Bug 102033 has been marked as a duplicate of this bug. ***

Comment 2 Roland McGrath 2003-08-09 22:44:57 UTC

The kernel is behaving correctly.  The zsh configure script runs a program
that does tcsetpgrp on fd 0 (stdin), which is broken in multiple ways.
If the input were redirected then the test would give a false negative.
Since the input is your terminal and the job is in the background, it rightly
gets SIGTTOU for trying to perform tcsetpgrp.  The only way a test of this
nature can be safe is if it's done on a specially created pty, e.g. in the child
of a forkpty call, but using ptys is not fully portable so zsh is kind of stuck
here.
If you would like to see this addressed, file a bug against zsh.

Comment 3 Michael Redinger 2003-08-10 11:30:48 UTC

Reopening and changing to zsh then.
(I suppose it is something similar with coreutils, therefore changing that one
from duplicate to reopen)

Comment 4 Jens Petersen 2003-11-25 05:30:33 UTC

Reproduced.

Comment 5 Jens Petersen 2003-11-25 08:10:52 UTC

Mailed zsh-users for input.

Comment 6 Jens Petersen 2003-11-26 08:43:58 UTC

http://www.zsh.org/mla/workers/2003/msg00895.html

Comment 7 Jens Petersen 2003-11-27 10:02:11 UTC

Patch from http://www.zsh.org/mla/workers/2003/msg00896.html
unfortunately breaks build in buildsystem ("no tty").

Adding weaker patch from
http://www.zsh.org/mla/workers/2003/msg00895.html
in zsh-4.0.7-2.

Comment 8 Jens Petersen 2004-01-13 06:22:03 UTC

Updating to better patch from upstream in 4.0.9-1.