Bug 681598

+++ This bug was initially created as a clone of Bug #597928 +++

Description of problem:

The symptom described in bug #597928 currently appears in Red Hat Enterprise Linux 5.6 (tcsh-6.14-17.el5_5.2, coreutils-5.97-23.el5_6.4).

Original description:

I've seen this in Fedora 13 and 11. I know that is used to work at least as far back as Fedora7, I'm not sure when it broke.

How reproducible:


Steps to Reproduce:
1. log in a user with tcsh shell
2. become root via su
3. type "suspend"
  
Actual results:

Nothing happens, you stay as root

Expected results:

It should do "Suspended (signal)" and put you back into your user shell

Additional info:

--- Additional comment from tre-bugzilla-redhat on 2010-07-03 18:25:42 EDT ---

Created attachment 429307 [details]
change to 1.22 file: properly propagate upstream stop signals in su

This is actually not a bug with tcsh, but with /bin/su in coreutils. The following recent change broke the behavior of "suspend" in tcsh, and affects Fedora 11, 12, 13, and rawhide:

http://cvs.fedoraproject.org/viewvc/devel/coreutils/coreutils-pam.patch?r1=1.21&r2=1.22

The issue lies with su attempting to propagate stop signals from its child (tcsh) to itself, which will notify its parent (presumably another shell). The previous version (1.21) was incorrect in that it always sent itself a SIGSTOP regardless of what type of signal was received (the "suspend" command in tcsh sends a SIGTSTP). This worked because SIGSTOP can't be blocked (masked). The 1.22 version attempted to fix this by directly propagating the signal, but failed for SIGTSTP because it was blocked. My patch fixes both problems. The relevant code change is:

+  /* tcsh sends SIGTSTP to the process group, and so is already pending */
   kill(getpid(), WSTOPSIG(status));
+  if (WSTOPSIG(status) != SIGSTOP) {
+    sigemptyset(&blockset);
+    sigaddset(&blockset, WSTOPSIG(status));
+    sigprocmask(SIG_UNBLOCK, &blockset, &ourset);
+    /* signal taken here */
+    sigprocmask(SIG_SETMASK, &ourset, NULL);
+  }

--- Additional comment from rhbugz.com on 2010-07-26 14:18:07 EDT ---

I've been having the same problem on both Fedora 12 and 13. So fare my workaround has been:

alias suspend kill -STOP $$

--- Additional comment from fedora-admin-xmlrpc on 2010-11-01 07:16:32 EDT ---

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.