Bug 91714 - (SIGNALS SMP)Signals behave weird
(SIGNALS SMP)Signals behave weird
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2003-05-27 11:38 EDT by Albert Fluegel
Modified: 2007-04-18 12:54 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-30 11:41:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Albert Fluegel 2003-05-27 11:38:09 EDT
Description of problem:
The problem shows up when installing the latest RPM-kernel update
(2.4.20-13.8bigmem), with the predecessor 2.4.18-27.8.0bigmem or
ealier everything is fine. Latest glibc update is also installed
like all RPM updates available from the RedHat web-site for 8.0.
Hardware is a Fujitsu Siemens HPC-Line 2 Processor Athlon 2200+
with a Tyan board. It does not matter, if APIC is disabled or not.

Problem is, that signals behave weird. Different phenomenons:

start sleep 1000 in the background:

prompt# sleep 1000 &
[1] 986

Now attach strace to the process:
prompt# strace -p 986
gettimeofday({1054049100, 159434}, NULL) = 0
nanosleep({972, 34012000}, 

Now press Ctrl-C. What happens now, is, that the shell says,
the sleep is suspended, ps reports status T and another strace
shows nothing. A kill -CONT 986 makes sleep 'run' again and
change to status S

start an arbitrary rpm Update: rpm -U /bla/bla/bla.rpm
what takes a while. Press Ctrl-C. The rpm goes to suspend
status, like i would expect pressing Ctrl-Z .

rpm update of the kernel (same RPM using -U --force) stops (sometimes,
unclear, in what situation) to do anything. strace shows, that the rpm
makes a call to pause() and waits. There are no child processes. An
strace with -f shows, that rpm starts a shell subprocess and this guy
in turn starts modprobe, what exits with _exit(-1) . The shell exits
with exit(0). The rpm process seems not to get any SIGCHLD. Probably
this is in fact an rpm problem, but i don't see the signal mask having
set the bit for SIGCHLD in /proc/<PID>/stat

Version-Release number of selected component (if applicable):
2.4.20-13.8bigmem shows the problems, any earlier does not.

How reproducible:
see above, example 1 is quite simple.

Steps to Reproduce:
Actual results:

Expected results:

Additional info:

IMHO it is not a TTY implementation problem, because of the rpm subprocess
Comment 1 Albert Fluegel 2003-05-27 11:40:01 EDT
The problem is not visible on a Dell Xeon single processor
with identical installation

Comment 2 Bugzilla owner 2004-09-30 11:41:00 EDT
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/

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