gnupg interfearance
I have a very strange problem that appears to have something to do with
gnupg. I have a number of applications that use real-time signals. When
I log into a particular machine, running SuSE 9.2, no realtime signals
are received by any of my applications. By the process of elimination I
have found that if I move aside a directory called .gnupg all my
applications work as they should. I have done no user configuration of
any of the gpg packages that are installed on this machine.
The contents of that directory are:
markh@harley:~> ls -Ral .gnupg/
.gnupg/:
total 24
drwx------ 3 markh users 4096 2005-01-12 16:01 .
drwxr-xr-x 47 markh users 4096 2005-01-12 16:04 ..
-rw------- 1 markh users 8538 2005-01-12 10:11 gpg.conf
drwx------ 2 markh users 4096 2005-01-12 15:59 private-keys-v1.d
-rw------- 1 markh users 0 2005-01-12 10:11 pubring.gpg
.gnupg/private-keys-v1.d:
total 8
drwx------ 2 markh users 4096 2005-01-12 15:59 .
drwx------ 3 markh users 4096 2005-01-12 16:01 ..
The private-keys-v1.d directory is empty but gets created every time I
login if the .gnupg directory exsist. The gpg.conf has things in it but
I've never touched it. I can remove this directory (.gnupg) and
everthing works for a time until that directory reappears for some reason???
I am very confused as to why anything in this directory could affect the
recept of realtime signals within an application. A simple sample
application that fails to recieve a realtime signal is follows:
#include
On Wednesday 12 January 2005 23:38, Mark Hounschell wrote: There are a no. of problems with this code :
#include
#include #include long prev_fact, i; /* global variables */ void SIGhandler(int); /* RT-SIGNAL handler */
void SIGhandler(int sig) { printf("\nReceived Signal.\n"); exit(0); }
you cannot call printf from a signal handler - it is not a defined safe function according to posix 1003.1-2003... Generally any I/O cannot be done from a signal handler. You also cannot call exit() - you must call _exit() directly so that any exit functions added by the atexit() in other parts of your code will not be executed.
int main(void) {
printf("About to send signal\n");
signal(SIGRTMIN + 5, SIGhandler); /* setup handler */ raise(SIGRTMIN + 5); /* fire the signal */
printf("We did not receive the signal Oops...\n"); exit(0);
}
The signal() call is deprecated. You should be using the POSIX signals as defined in sigaction() and related functions. Usually all signal handlers do is set a global flag of type sigatomic_t. It is up to the calling function test the global flag and take appropriate action. 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 -- Paul Hewlett (Linux #359543) Email:`echo az.oc.evitcaten@ttelweh | rev` Tel: +27 21 852 8812 Cel: +27 72 719 2725 Fax: +27 86 672 0563 --
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
Mark Hounschell wrote:
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.
I was mistaken, I can in fact move this directory into my home dir on another 9.2 box and recreate the problem? Regards Mark
The Thursday 2005-01-13 at 06:13 -0500, Mark Hounschell wrote:
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?
I'll make a very wild guess - I don't have real knowledge of this, but I have a suspicion. KDE does lots of things, and it has a kind of gnupg agent for use by programs needing gpg. Probably, if there is a .gnupg directory this program or whatever gets started and provides services. Then, it will be this program which is interacting with yours strangely. You could have a look around these: /opt/kde3/bin/kgpg /opt/kde3/bin/kgpgcertmanager /opt/kde3/share/apps/kgpg /opt/kde3/share/apps/kgpgcertmanager -- Cheers, Carlos Robinson
Carlos E. R. wrote:
I'll make a very wild guess - I don't have real knowledge of this, but I have a suspicion.
KDE does lots of things, and it has a kind of gnupg agent for use by programs needing gpg. Probably, if there is a .gnupg directory this program or whatever gets started and provides services. Then, it will be this program which is interacting with yours strangely.
You could have a look around these:
/opt/kde3/bin/kgpg /opt/kde3/bin/kgpgcertmanager /opt/kde3/share/apps/kgpg /opt/kde3/share/apps/kgpgcertmanager
Thanks. But what I've found is, if there is a .gnupg directory present in my home directory and I am logging it at the console via KDM, my kde session appears to start via the following command: gpg-agent --daemon --no-detach --keep-display ssh-agent /etc/X11/xinit/xinitrc If the .gnupg directory does not exsist my session starts with the following command: ssh-agent /etc/X11/xinit/xinitrc When my session starts via the gpg-agent, no realtime signals can be received by any of my applications. It appears the gpg-agent is causing me to inherate some sort of blocking mask. Don't know if that is "proper" or not but have found that if I just use sigprocmask to insure the signals I want to use are in fact unblocked, I'm ok. I wish I could find some information about this "inherated blocking mask" though because I'm not very comfortable that I should "HAVE" to do this. Regards Mark
The Monday 2005-01-17 at 05:17 -0500, Mark Hounschell wrote:
It appears the gpg-agent is causing me to inherate some sort of blocking mask. Don't know if that is "proper" or not but have found that if I just use sigprocmask to insure the signals I want to use are in fact unblocked, I'm ok. I wish I could find some information about this "inherated blocking mask" though because I'm not very comfortable that I should "HAVE" to do this.
Ah, that is around the lines of what I suggested, I wasn't too off-track. But I can not give you further information: in Linux programing I'm but a novice. I remember some strange question about that program, or some strange behavior reported here time ago, perhaps around two years. My fuzzy-online-biological-memory says it is related, but being fuzzy and unreliable I can't pinpoint you to the exact source. I would suggest you try one of the programming lists, perhaps one not dedicated to SuSE. [...] I tried grepping my archive, but it found 3500 hits: cer@nimrodel:~/Mail> grepmail -b -i -M -m -R -u -e "gpg-agent" lists/* > busqueda There is something broken with grepmail, because I can not find the word gpg-agent in many of those emails... with some searches I did another day, it complained of programming errors. Perhaps you can with google. I'm not online to try, and I never remember the syntax. -- Cheers, Carlos Robinson
The Monday 2005-01-17 at 05:17 -0500, Mark Hounschell wrote: I just said a minute ago:
I remember some strange question about that program, or some strange behavior reported here time ago, perhaps around two years. My fuzzy-online-biological-memory says it is related, but being fuzzy and unreliable I can't pinpoint you to the exact source.
And then I found this, as I was about to delete the temporary folder
after my search:
|> Date: Thu, 19 Feb 2004 06:32:00 -0500
|> From: Bob Pearson
|> To: SuSE-Linux-English
participants (4)
-
Carlos E. R.
-
Mark Hounschell
-
Mark Hounschell
-
Paul Hewlett