preventively clear blocked signals in case they were inherited by the…

[SSSSeb]

… launcher process

lbzip2 requires a set of signals to properly work. (SIGUSR2 is one of them)

If the caller process of lbzip2 has blocked some of those signals then the blocked list is inherited and lbzip2 will not work.

This happens for example if you invoke lbzip2 from inside an RPM for CENTOS8 or SLES15SP2.

This patch is simply clearing the way (at the process level in setup_signals) to prepare for a functionnal lbzip2 whatever the caller status is in term of blocked signals.

replacing lbzip2 by bunzip2 in my use-case showed that only lbzip2 was impacted, very likely because lbzip2 only requires such requirements on signals.

I believe it is wrong that RPM is blocking signals but I think this is good to clear the way. When not having this patch, lbzip2 would uncompress the tarball and would hang forever (because the SIGUSR2 signal required was blocked between the main thread and the workers thread).

hope this helps.

[tansy]

How can one emulate it to check it?

[SSSSeb]

You could recompile the following and use it to launch an lbzip2 decompression. This will stall forever if you use lbzip2 master branch and should proceed with my patch.

#include <stdio.h>
#include <stdlib.h>
#include <signal.h>

void main(int argc, char**argv)
{
sigset_t myfullset;

if (sigfillset(&myfullset)) {
fprintf(stderr,"error filling set\n");
exit(1);
}

if (sigprocmask(SIG_BLOCK,&myfullset,NULL)) {
fprintf(stderr,"error blocking all signals with sigprocmask\n");
exit(1);
}
system(argv[1]);
}

[tansy]

I tested it and it does work.

Do you have to block all signals? I guess not.

And if RPM blocks some of them does it do it for a reason and if so then for what reason?
Shall it be asked RPM devs?

[SSSSeb]

I tested it and it does work.

Do you have to block all signals? I guess not.

probably not, but this was my reproducer of the RPM behavior (I used strace and found that they block all signals).

And if RPM blocks some of them does it do it for a reason and if so then for what reason? Shall it be asked RPM devs?

I've looked in the RPM source code tree and they have removed this signal blocking a long time ago but main linux distros are not up-to-date with upstream rpm devs

My conclusion is: if the signal is blocked then lbzip2 will not work at all, so we should unblock it or test and do an early exit. Stalling forever is not good for lbzip2 compared to all others. my 2 cents.

[tansy]

Thanks for the answer.

Regarding the code, IMO the third line of the comment (`such as rpm tools as of CENTOS8/SLES15') is unnecessary detail that shouldn't be in code. It would better be in description, even could find a place in ChangeLog but code is not place for such information.

[SSSSeb]

I agree with you, I should not have put those comments in the code, they do not belong here.

[SSSSeb]

what should I do next, remove the line and propose a commit wihtout the extra comment line instead or do you want to do that ?

[SSSSeb]

just in case, I pushed force a different commit to accomodate better your comment.

[tansy]

I wonder if it will ever be done as this project seems abandoned. Last @kjn's activity was in 2018.