Re: SIGUSR1 inside postinst etc scripts

[Jason Gunthorpe <jgg@ualberta.ca>]

On Wed, 4 Aug 1999, joost witteveen wrote:

> > Strace apt-get's main program and examine it for manipulations of signals.
> > On the effected computer you might see that it gets masked off - send me a
> > trace if possible and we can find+kill the glibc people 
> 
> Do you mean something like
> 
> [pid 10973] sigprocmask(SIG_BLOCK, ~[], [USR1]) = 0
> 
> That I can find. But I am not quite sure what to look for.

Yep, that and the sigprocmask SIG_BLOCK it does later on. Simple test:

#include <unistd.h>

int main(int argc, const char *argv[])
{
   if (fork() == 0)
   {
      execvp(argv[1],argv+1);
   }
   
   return 0;
}

Compile it normally and run './a.out sleep 1000' and investigate the
signal mask, repeat but compile it with -lpthreads - notice that sleep no
longer responds to SIGUSR1 and that the signal is (maybe) masked and
blocked. I did my testing on glibc 2.0  but I'll try it on pandora in a
bit. 

So yes, pthread is to blame. I don't need to use it anymore (it is in
there for a prototype GUI) so what I think is best is to just remove it
from APT - I have a sneaky suspicion that it is to blame for numerous
other failures on other arch's which I am just verifying right now.

Right now - to fix your bug, you can probably simply restore sigusr1 to an
unblocked status using sigprocmask.

Jason