Bug 102042 - process stops when backgrounding
Summary: process stops when backgrounding
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: zsh
Version: 1
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jens Petersen
QA Contact: Mike McLean
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-08-09 15:54 UTC by Michael Redinger
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2004-01-13 06:25:46 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

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.


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