Bug 77390 - SIGRTMIN+x not delivered ?
SIGRTMIN+x not delivered ?
Status: CLOSED NEXTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
8.0
All Linux
medium Severity high
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-11-06 03:34 EST by pascal.lengard
Modified: 2016-11-24 10:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-08-04 16:22:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description pascal.lengard 2002-11-06 03:34:57 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021016

Description of problem:
Problem with dnotify (I use dnotify for various purposes):
the example program from /usr/src/linux/Documentation/dnotify.txt does not work
on RedHat 8.0 , it does work on RedHat 7.3 .

I tried the 2.4.18 kernel from redhat 7.3 but it did not correct the problem.
Problem seems more glibc. SIGRTMIN is not delivered to the process.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.compile the example from /usr/src/linux/Documentation/dnotify.txt
2.execute program: ./dnotify
3.on redhat 7.3, issuing a "kill -SIGRTMIN" on this process has the intended
effect. on redhat 8.0 it does not (seems that signal is never delivered).
	

Actual Results:  nothing

Expected Results:  dnotify example should print something like "got event on fd 500"

Additional info:


this bug migh bite other softwares too.

I used strace on FAM daemon (which is supposed to use dnotify) and saw it using
timers and polling ... is this normal behaviour or related to this ??
Comment 1 pascal.lengard 2002-11-13 09:15:25 EST
I tested with glibc-2.3.1-2 from jakub's developer section RPMs,
behaviour is still strange but different:

although it registers SIGRTMIN to dnotify's kernel facility, it seems
to only receive SIGIO. furthermore still no way to send SIGRTMIN with
manual "kill -SIGRTMIN" command ...
Comment 2 Jakub Jelinek 2002-11-13 16:57:41 EST
Update ;) Should work just fine in e.g. glibc-2.3.1-6.
2002-10-29  Andreas Schwab  <schwab@suse.de>

        * sysdeps/generic/allocrtsig.c: Include <testrtsig.h>, not
        "testrtsig.h".  Reported by Daniel Jacobowitz <dan@debian.org>.
Comment 3 pascal.lengard 2002-11-14 03:56:00 EST
hummm , I just upgraded to glibc-2.3.1-6 and it behaves just as badly :-(
I even re-compiled the dnotify example and rebooted to make sure new libc was used.

still no way to send SIGRTMIN to this process ...

Comment 4 Jakub Jelinek 2002-11-14 04:54:06 EST
Works just fine for me:
$ rpm -q glibc
glibc-2.3.1-6
$ /tmp/dnotify
Got event on fd=3
Got event on fd=0

On another vt:
$ touch A
$ kill -SIGRTMIN `pidof dnotify`
Comment 5 pascal.lengard 2002-11-14 08:42:58 EST
huh ? strange.

It still does not work on my setup. I have only one redhat 8.0 host so I can not
test on other systems (others are running redhat 7.3 and dnotify does work on
it). I might upgrade another one to test.
I got redhat 8.0 from iso cdrom download and am still running original kernel
from the distribution (2.4.18-3).

I got glibc-2.3.1-6 this morning from rawhide (found with google on rpmfind).

[root@wdell tmp]# rpm -q glibc
glibc-2.3.1-6
[root@wdell tmp]# rpm --verify glibc
[root@wdell tmp]#

when I strace /tmp/dnotify , it just sits on pause() call :
root@wdell tmp]# strace ./dnotify
execve("./dnotify", ["./dnotify"], [/* 24 vars */]) = 0
uname({sys="Linux", node="wdell.chezmoi.fr", ...}) = 0
brk(0)                                  = 0x80496f0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40013000
open("/etc/ld.so.preload", O_RDONLY)    = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=55790, ...}) = 0
old_mmap(NULL, 55790, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40014000
close(3)                                = 0
open("/lib/i686/libc.so.6", O_RDONLY)   = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@Z\1B4\0"..., 1024) = 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=1374147, ...}) = 0
old_mmap(0x42000000, 1207748, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x42000000
mprotect(0x42120000, 28100, PROT_NONE)  = 0
old_mmap(0x42120000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0x120000) = 0x42120000
old_mmap(0x42125000, 7620, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x42125000
close(3)                                = 0
munmap(0x40014000, 55790)               = 0
rt_sigaction(SIGRTMIN, {0x8048494, [], SA_RESTORER|SA_SIGINFO, 0x42028320},
NULL, 8) = 0
open(".", O_RDONLY)                     = 3
fcntl64(3, F_SETSIG, 0x20)              = 0
fcntl64(3, 0x402 /* F_??? */, 0x80000006) = 0
pause(


even kill -SIGRTMIN does nothing.

hey ! kill -SIGRTMIN+1 is sent to the process:
strace output:
pause()                                 = ? ERESTARTNOHAND (To be restarted)
--- SIGRT_1 (Real-time signal 1) ---
+++ killed by SIGRT_1 +++

wait a second :-) I will change all "SIGRTMIN" with "SIGRTMIN+1" in dnotify.c
(example from kernel doc) ... make dnotify
and VOILA it works like a charm with SIGRTMIN+1.
when I "kill -SIGRTMIN `pidof dnotify`" nothing happens (I though I would get
same message: killed by SIGRT_...).

I revert to original kernel example dnotify.c, make dnotify ...
and ... it still does not work !!
(still no way to send SIGRTMIN to it)

I am open to new tests that I could run to debug this.
what could be the difference between our setups ?

Comment 6 pascal.lengard 2002-11-17 10:42:35 EST
I re-read my last message and think it's not as clear as it should.

I run redhat 8.0 installed from scratch (not an upgrade) on witch I applied all
fix available except kernel one (break sound driver on my laptop).
kernel is still:
[plg@wdell plg]$ cat /proc/version
Linux version 2.4.18-14 (bhcompile@stripples.devel.redhat.com) (gcc version 3.2
20020903 (Red Hat Linux 8.0 3.2-7)) #1 Wed Sep 4 13:35:50 EDT 2002

since found this bug, I upgraded with glibc-2.3.1-6 found on rpmfind since not
available on redhat ftp:
[plg@wdell plg]$ rpm -qi glibc
Name        : glibc                        Relocations: (not relocateable)
Version     : 2.3.1                             Vendor: Red Hat, Inc.
Release     : 6                             Build Date: Fri Nov  8 02:49:28 2002
Install date: Thu Nov 14 09:33:27 2002      Build Host: tweety.devel.redhat.com
Group       : System Environment/Libraries   Source RPM: glibc-2.3.1-6.src.rpm
Size        : 8546831                          License: LGPL
Signature   : (none)
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>



Now, I can "kill -SIGRTMIN+1" a process but I can still not "kill -SIGRTMIN".
Means that the dnotify example works when changed to use SIGRTMIN+1, but still
does not work with original C source.

any idea ??
where should I look now ?
I looked at glibc sources and saw that RT signals are tested using only
(RTMIN+RTMAX)/2 signal which works on my system ...
Comment 7 pascal.lengard 2002-11-28 09:29:33 EST
Just made some more tests.
I now have 2 systems installed from scratch with redhat 8.0
They both behave exactly the same.
One is up-to-date (kernel-2.4.18-18.8.0 , glibc-2.3.1-6 )
the other one is raw from redhat 8.0 cdrom.

test is sending SIGRTMIN signals with "kill -SIGRTMIN".

on a redhat 7.3 system, sending SIGRTMIN to a process is possible
and if no handler is defined we get "Real-time signal 0" message and
process ends.

on the 2 redhat 8.0 systems, sending SIGRTMIN does nothing.

I even tried something more: I took libc.so.6 and its dependances from the
7.3 system and put it in /tmp/foo on one 8.0 system with a LD_LIBRARY_PATH=/tmp/foo.
from this shell using kill -31  (SIGRTMIN) still does not work but kill -32 does.

i really still do not understand what could be going on ...
Comment 8 Jakub Jelinek 2002-11-28 09:37:33 EST
kill -31 ??
SIGRTMIN is 32.
Comment 9 pascal.lengard 2002-11-28 10:43:19 EST
sorry, of course you are right.
the mistake is in my report, I should have written:
-----
I even tried something more: I took libc.so.6 and its dependances from the
7.3 system and put it in /tmp/foo on one 8.0 system with a LD_LIBRARY_PATH=/tmp/foo.
from this shell using kill -32  (SIGRTMIN) still does not work but kill -33 does.
-----

for unknown raison (to me), in the LD_LIBRARY_PATH setting above you can not use
the name "SIGRTMIN" and have to use numbers...


Jakub, I don't want to bug you too much with this,
you said that it was working on your systems, 
how far are they from a raw redhat 8.0 system ? 
Have you been able to reproduce the problem ??
Comment 10 Ulrich Drepper 2003-04-22 01:35:44 EDT
You can use only the signals with the values between which SIGRTMIN and SIGRTMAX
return *at* *runtime*.  SIGRTMIN at runtime is with NPTL 33, with LinuxThreads
34 (IIRC).  It is not possible to use the signals 32 (and 33 for LT) for
anything, they are used by glibc internally.
Comment 11 pascal.lengard 2003-04-24 04:09:50 EDT
OK. I got it.
There was a problem with original redhat 8.0 glibc.

Jakub's first advice was correct, but I kept testing the signal
delivery with simple "kill" command ... and although this *was*
working on redhat 7.3 it is no more supported on redhat 8.0

My testing method was bad, things have been working like a charm
since months. 

Thank you both for your help !
Comment 12 Bill Nottingham 2006-08-04 16:22:39 EDT
Red Hat Linux and Red Hat Powertools are currently no longer supported by Red
Hat, Inc. In an effort to clean up bugzilla, we are closing all bugs in MODIFIED
state for these products.

However, we do want to make sure that nothing important slips through the
cracks. If, in fact, these issues are not resolved in a current Fedora Core
Release (such as Fedora Core 5), please open a new issues stating so. Thanks.

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