This seems to only happen in mock. Scriptlets run from %transfiletriggerin get a big pile of input on stdin from rpm containing the list of triggering files, and, when run from mock, the %transfiletriggerin scriptlet raises SIGPIPE, which crashes rpm. See also bug 1264198. I'm not saying that's a not a bug in rpm, but I'm not saying it's not a bug in man-db, either. This is blocking anaconda testing in rawhide.
Mock uses dnf on fedora rawhide. There isn't problem with yum-deprecated. You might find more info in BZ1267492. There is simple reproducer using docker instead of mock. But symptoms are the same.
*** Bug 1267492 has been marked as a duplicate of this bug. ***
I am not sure that the bug is in man-db. It works with yum and also it works with dnf + tty. More details are in duplicated BZ (which was filed before this one :-) https://bugzilla.redhat.com/show_bug.cgi?id=1267492#c0
No. I already explained what's going on. The exact behavior may change depending on the particular arrangement of input buffers and terminal file descriptors and such, but this ultimately comes down to, 1) man-db has requested that rpm write a boatload of data to man-db's input pipe, and 2) man-db does not read from this pipe. That's the definition of a SIGPIPE.
Could you exaplain why it works with yum (yum-deprecated)?
I don't know, and it doesn't matter. Maybe dnf is running faster and able to get more data into the stdin buffer than yum can.
I'm unable to reproduce this, but I think SIGPIPE can be avoided by adding "cat > /dev/null" as the first commmand in %transfiletriggerin scriptlet, so that mandb gets nothing on stdin.
(In reply to Nikola Forró from comment #7) > I'm unable to reproduce this, but I think SIGPIPE can be avoided by adding > "cat > /dev/null" as the first commmand in %transfiletriggerin scriptlet, so > that mandb gets nothing on stdin. The simplest reproducer is to use docker without tty. BTW. It works on fedora 23 which has older version of man-db man-db-2.7.1-10.fc23 So I tried to bisect it on fedora rawhide. The first broken version is man-db-2.7.3-2.fc24. The change-log says: "use file triggers instead of crontabs for updating cache". # docker run --rm fedora:rawhide sh -c "dnf update -y dnf rpm && dnf --rpmverbosity=debug --verbose install -y https://kojipkgs.fedoraproject.org//packages/man-db/2.7.3/1.fc24/x86_64/man-db-2.7.3-1.fc24.x86_64.rpm"
Do file triggers work with yum(yum-deprecated)? Otherwise it seems to be some issue with dnf+rpm.
(In reply to Lukas Slebodnik from comment #9) > Do file triggers work with yum(yum-deprecated)? Yes, they do. (In reply to Lukas Slebodnik from comment #8) > The simplest reproducer is to use docker without tty. Right, I'm not sure what I did wrong last time but I was unable to catch this. However, the "cat > /dev/null" solution seems to be working. Any objections against it?
(In reply to Nikola Forró from comment #10) > (In reply to Lukas Slebodnik from comment #9) > > Do file triggers work with yum(yum-deprecated)? > Yes, they do. > > (In reply to Lukas Slebodnik from comment #8) > > The simplest reproducer is to use docker without tty. > Right, I'm not sure what I did wrong last time but I was unable to catch > this. > > However, the "cat > /dev/null" solution seems to be working. Any objections > against it? Yes, it might work. But if it is a general problem with dnf + file triggers(rpm) than the same problem can occur in other packages. It would be good to avoid such workarounds as "cat > /dev/null" in every package which will use file triggers. Or at least it should be properly documented. This is a reason why there is need-info flag "(lkardos)"
For now you can use workaround with "cat > /dev/null" but this has to be fixed in rpm.
Closing this, as the problem was fixed in bug 1264198.