Bug 79859 - Processes Ignoring Signals
Summary: Processes Ignoring Signals
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: vnc
Version: 8.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Tim Waugh
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2002-12-17 16:36 UTC by Ronald W. Heiby
Modified: 2007-04-18 16:49 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2006-10-11 12:58:29 UTC

Attachments (Terms of Use)

Description Ronald W. Heiby 2002-12-17 16:36:59 UTC
Description of problem:
Under RH 8.0, I use vncserver to create a VNC X Server session. I connect to 
that session using a Windows-based client application. Within a Gnome Terminal, 
I run command-line programs. These commands do not respond to ctrl-c.

On further investigation, I determined that the programs are being started with 
signals 2, 3, and 13 set to SIG_IGN. This is not the case when I perform the 
same operations under RH 7.2 (Enigma), nor is it the case when I log into a 
Gnome session at the console or when I log into an SSH command prompt.

VNC packages under RH 8.0 are 3.3.3r2-39.
VNC packages under RH 7.2 are 3.3.3r2-18.4.

Note: I have not examined any signals beyond #39.
Note: I have not tried the latest (3.3.6) VNC.

How reproducible:

Steps to Reproduce:
1. Compile and run the following program.
Actual results:
Signals 2, 3, and 13 are set to SIG_IGN, rather than the correct SIG_DFL.

Expected results:
Signals are expected to default to SIG_DFL.

Additional info:

#include <signal.h>
#include <stdio.h>

main() {
	int i;
	__sighandler_t rwh;

	printf("SIG_IGN: %x\n", SIG_IGN);
	printf("SIG_DFL: %x\n", SIG_DFL);

	for (i = 1; i < 40; i++) {
		rwh = signal(i, SIG_DFL);
		printf("%d: %x\n", i, rwh);

Comment 1 Tim Waugh 2002-12-23 13:04:39 UTC
I couldn't reproduce this problem with 3.3.3r2-43.  Was it a fresh install or an

Comment 2 Ronald W. Heiby 2002-12-27 04:56:01 UTC
The RH 8.0 installs were clean installs, not upgrades. As far as I have been 
aware, 3.3.3r2-39 is the current released package for RH 8.0. I am unaware of 
the availability of 3.3.3r2-43, but would be happy to try it out in my shop.

Comment 3 Ronald W. Heiby 2003-01-16 00:47:20 UTC
I have downloaded and installed the 3.3.6 version of VNC directly from the 
developers' web site. With it, also, I see signals 2 and 3 ignored in my shell 
windows. Signal 13 is SIG_DFL, as I would expect. My /etc/passwd entry has a 
shell of /bin/bash.

Comment 4 Need Real Name 2003-02-10 05:12:21 UTC
Yes, I have this problem, too, under 8.0 with vnc-server-3.3.3r2-39.

Comment 5 Need Real Name 2003-02-10 06:35:55 UTC
Problem exists with vnc-server-3.3r3r2-43 (from phoebe beta), too.

Comment 6 Ronald W. Heiby 2003-04-08 15:14:01 UTC
This continues to be a pretty big deal, since most of my access to my RH 
systems is via VNC. Having to remember to suspend the task with Ctrl-Z and then 
issue a kill (rather than just a Ctrl-C) is a fairly pathetic workaround, and 
is not always possible. An update on where this stands would be appreciated. 

Comment 7 Tim Waugh 2003-04-09 08:51:05 UTC
I still can't reproduce the problem.  I do see SIGQUIT ignored, but nothing
else.  Control-C works as normal.

Fresh install of Red Hat Linux 9, updates applied. (But I saw the same thing
with Red Hat Linux 8.0.)

Comment 8 Ronald W. Heiby 2003-06-30 06:44:52 UTC
Perhaps someone could provide me with a list showing what processing happens in 
the construction of the VNC environment, from the point when it is initially 
invoked out of the /etc/rc5.d/S99vncserver until the X Window desktop is ready 
for action. Given such a list, I might be able to trace through the process and 
determine where things are diverging.

Anything that would highlight what differences may exist between a VNC X Window 
session and an X Window session for the same user at the main system console 
would be especially helpful in tracking this down.


Comment 9 Ronald W. Heiby 2003-08-21 21:17:31 UTC
Here's the latest I've learned.

If I change the terminal creation settings via [Red Hat Button] | Extras | 
Preferences | Preferred Applications, and choose not to use gnome-terminal, but 
instead xterm (or, better uxterm for UTF-8 support), then signals work just as 
I would expect.

If, from one of these xterm windows, I invoke a gnome-terminal, then signals in 
that window work as I would expect.

However, if I have gnome-terminal as the desired terminal window type, and 
create one by right-clicking on the desktop and choosing "New Terminal", then 
signals 2 and 3 are ignored in that window. Likewise, the gnome-terminal 
windows that get created automatically at login time as part of my saved 

Is xterm explicitly setting SIGINT and SIGQUIT to the default? Or is some other 
mechanism at work?

Comment 10 Tim Waugh 2003-10-21 09:45:50 UTC
I would be interested to know if this behaviour is still visible in the current
test version (Severn).

Comment 11 Bill Nottingham 2006-08-07 19:45:45 UTC
Red Hat Linux is no longer supported by Red Hat, Inc. If you are still
running Red Hat Linux, you are strongly advised to upgrade to a
current Fedora Core release or Red Hat Enterprise Linux or comparable.
Some information on which option may be right for you is available at

Red Hat apologizes that these issues have not been resolved yet. We do
want to make sure that no important bugs slip through the cracks.
Please check if this issue is still present in a current Fedora Core
release. If so, please change the product and version to match, and
check the box indicating that the requested information has been
provided. Note that any bug still open against Red Hat Linux on will be
closed as 'CANTFIX' on September 30, 2006. Thanks again for your help.

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