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: Very 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); } }
I couldn't reproduce this problem with 3.3.3r2-43. Was it a fresh install or an upgrade?
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.
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.
Yes, I have this problem, too, under 8.0 with vnc-server-3.3.3r2-39.
Problem exists with vnc-server-3.3r3r2-43 (from phoebe beta), too.
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. Thanks.
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.)
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. Thanks!
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 configuration. Is xterm explicitly setting SIGINT and SIGQUIT to the default? Or is some other mechanism at work?
I would be interested to know if this behaviour is still visible in the current test version (Severn).
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 http://www.redhat.com/rhel/migrate/redhatlinux/. 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.