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 ??
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 ...
Update ;) Should work just fine in e.g. glibc-2.3.1-6. 2002-10-29 Andreas Schwab <schwab> * sysdeps/generic/allocrtsig.c: Include <testrtsig.h>, not "testrtsig.h". Reported by Daniel Jacobowitz <dan>.
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 ...
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`
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 ?
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.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 ...
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 ...
kill -31 ?? SIGRTMIN is 32.
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 ??
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.
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 !
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.