Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 154065 - control not returned to stopped job when fg issued
Summary: control not returned to stopped job when fg issued
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: vixie-cron
Version: 4.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Jason Vas Dias
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks: 170785
TreeView+ depends on / blocked
 
Reported: 2005-04-06 23:04 UTC by Stephen Gardner
Modified: 2007-11-30 22:07 UTC (History)
0 users

Fixed In Version: vixie-cron-4.1-36.EL4
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-05-01 17:44:25 UTC


Attachments (Terms of Use)

Description Stephen Gardner 2005-04-06 23:04:52 UTC
[ NOTE: this may be an issue with  vi  or  crontab  as I have only found one
method of invoking this problem currently which involves using those commands ]

Description of problem:

Version-Release number of selected component (if applicable):
RHEL4-AS-U0 (i386 and x86_64)
bash-3.0-19.2
vim-minimal-6.3.046-0.40E.4
vixie-cron-4.1-20_EL

How reproducible:
Always (as root and non-root user)

Steps to Reproduce:
1. crontab -e
2. Press  Control-Z  (receive   "[1]+  Stopped crontab -e"  output)
3. fg  (or fg %1)
4a. Press  enter   (you should find you are still at the command prompt)
4b. fg   again to get back into  crontab  editor (vi)

[ this can be reproduced if others backgrounded running / stopped jobs exist ]

Actual results:
User is left at command problem unexpectedly and has to foreground crontab twice.

Expected results:
User is returned to previously stopped program

Additional info:
This does not happen on RHEL3-U4 where control is returned to crontab as expected.

Comment 1 Stephen Gardner 2005-04-07 13:47:40 UTC
This problem also occurs on Fedora RAWHIDE (sync'd 7 April 2005) with
bash-3.0-30
vixie-cron-4.1-28_FC4
vim-minimal-6.3-068-1


Comment 2 Tim Waugh 2005-04-07 13:52:14 UTC
I can reproduce the problem on Red Hat Enterprise Linux 4.  Replacing the bash
package with the one for RHEL3-U4 (bash-2.05b-29.0.3) does *not* make the
problem go away.

Concluding that vixie-cron is at fault and setting component.

Comment 3 Jason Vas Dias 2005-04-07 18:02:05 UTC
Yes, this is a problem - I've duplicated it with vixie-cron-4.1 on FC4 & FC3.

It seems vixie-cron-4.1's crontab is being over-zealous in using:
    waitpid(child, &exit_status, WUNTRACED)
which returns when child gets a SIGSTOP (when not under trace)
whereas vixie-cron-3.0.1 just uses
    wait(&exit_status)
which does not return on a SIGSTOP sent to the child.

Even worse, vixie-cron-4.1 crontab reacts to the exit status WIFSTOPPED
by killing itself with SIGSTOP, depending on itself getting a SIGCONT
when vi gets a SIGCONT; but there are problems in the kernel with 
propagating SIGCONT from child to parent. So the first SIGCONT 
resumes vi which displays its screen, but as the SIGCONT is not
propagated, crontab is still stopped, and as the child of a stopped
process group, vi goes into the background again. It is necessary
to send SIGCONT again to the process group leader (crontab) to put
vi into the foreground again.

I can't understand why this change to kill itself with SIGSTOP 
when the editor child is stopped was made in vixie-cron-4.1 and I'm
backing it out.

This issue is now fixed with vixie-cron-4.1-30_EL, which should be
in RHEL-4-U2. Meanwhile, you can download it from:
 http://people.redhat.com/~jvdias/CRON/RHEL-4/4.1-30_EL






Comment 4 Stephen Gardner 2005-04-07 18:45:23 UTC
Jason, thank you for the speedy resolution and in particular for the detailed
explanation of the signal handling propagation issue which caused it to occur. I
have confirmed the -30 release you provided works as expected on RHEL4-U0 i386
and x86_86.



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