Paul Hewlett wrote:
Which kernel are you using ? Maybe you have tripped up on some weird interaction between signal(), SIGRTMIN and your kernel version... The signal() called may not support correctly the newer signals such as SIGRTMIN.
Paul H
Yes, yes, this is just a simple example that shows the problem. I do in fact use sigaction in my applications and I don't do any I/O from within any signal handlers. I am using SuSE's 2.6.8-24.5-smp kernel currently but have tried this with 2.6.10 vanilla and a patched version of 2.4.26. Other machines in which I do have a .gnupg directory, I do not have that empty private-keys-v1.d directory either. All I have is -rw------- 1 markh users 8538 2004-12-04 07:05 gpg.conf -rw------- 1 markh users 0 2004-12-04 07:05 pubring.gpg -rw------- 1 markh users 0 2004-12-04 07:05 secring.gpg I've also noticed this only occurs when I login via KDM. If I am at run level-3 or ssh into the box then I don't have this problem. And as I said if I just remove that directory and re-login, all is fine for a few days, until this directory mysteriously reappears with the same contents. I have actually copied this directory (in its broken form) onto another machine into my account and the problem does not seem to follow the directory. Even so, I cannot help but think it has something to do with gnupgp. What causes this directory to be created? Why are its contents different on this machine? How could gnupgp or pgp affect my environment such that I cannot receive realtime signals. The same program using SIGUSR1 or SIGUSR2 will function ok? markh@harley:~> rpm -qa | grep gpg gpg2-1.9.10-3 gpg-1.2.5-3 gpgme-0.9.0-2 libgpg-error-0.7-6 libgpg-error-devel-0.7-6 gpg-pubkey-9c800aca-40d8063e gpg-pubkey-3d25d3d9-36e12d04 ?? Thanks and Regards Mark