Red Hat Bugzilla – Bug 154065
control not returned to stopped job when fg issued
Last modified: 2007-11-30 17:07:17 EST
[ 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.
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
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.
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
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.