Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rpmbuild sometimes is killed by SIGPIPE with bad dependency generator sciptlets #2949

Closed
mlschroe opened this issue Mar 6, 2024 · 4 comments · Fixed by #2958
Closed

rpmbuild sometimes is killed by SIGPIPE with bad dependency generator sciptlets #2949

mlschroe opened this issue Mar 6, 2024 · 4 comments · Fixed by #2958
Labels

Comments

@mlschroe
Copy link
Contributor

mlschroe commented Mar 6, 2024

This is a bit of a corner case, but I just received a bug report that builds sometimes terminate for a specific package. It turned out the package contained this little gem:

%define __perllib_provides /bin/true

Anyway, I don't think rpm should be killed by this. Once upon a time getOutputFrom() had code that made it ignore SIGPIPE, but it seems it was removed in commit 375a6b5

This is probably not urgent to fix, just filing so that you know about this race.

@mlschroe
Copy link
Contributor Author

mlschroe commented Mar 6, 2024

@pmatilai
Copy link
Member

pmatilai commented Mar 6, 2024

Oh, that sounds a whole lot like #2470

@pmatilai
Copy link
Member

pmatilai commented Mar 6, 2024

The flaky test-case is:

#!/bin/sh
echo 'bad = *'
EOF
chmod a+x "${RPMTEST}"/tmp/bad.req

runroot rpmbuild -bb --quiet \
                --define "__script_requires /tmp/bad.req" \
                /data/SPECS/shebang.spec

The common theme being a tiny generator that outputs little to nothing.

@mlschroe
Copy link
Contributor Author

mlschroe commented Mar 6, 2024

You probably already know this, but rpmbuild is killed by the write() system that writes the filelist to the generator being done after the child has exited.
I think the only way to prevent this is to ignore SIGPIPE before calling write(). Everything else like the select() thing we currently do is not race free.

pmatilai added a commit to pmatilai/rpm that referenced this issue Mar 11, 2024
If a dependency generator dies while we're still writing to its stdin,
it causes us to die rather randomly. Typically happens with fake
dependency generators that don't actually bother reading their input
and/or write anything back. This is almost certainly the ghost failure
we've occasionally seen in the test-suite too (rpm-software-management#2470).

Resurrect the explicit SIG_IGN that got removed apparently in commit
375a6b5. The matter was further
confused by NSPR (which we once relied on) always setting SIGPIPE
to SIG_IGN.

Suggested-by: Michael Schroeder <mls@suse.de>

Fixes: rpm-software-management#2949
pmatilai added a commit to pmatilai/rpm that referenced this issue Mar 11, 2024
If a dependency generator dies while we're still writing to its stdin,
it causes us to die rather randomly. Typically happens with fake
dependency generators that don't actually bother reading their input
and/or write anything back. This is almost certainly the ghost failure
we've occasionally seen in the test-suite too (rpm-software-management#2470).

Resurrect the explicit SIG_IGN that got removed apparently in commit
375a6b5. The matter was further
confused by NSPR (which we once relied on) always setting SIGPIPE
to SIG_IGN.

Suggested-by: Michael Schroeder <mls@suse.de>

Fixes: rpm-software-management#2949
pmatilai added a commit to pmatilai/rpm that referenced this issue Mar 11, 2024
If a dependency generator dies while we're still writing to its stdin,
it causes us to die rather randomly. Typically happens with fake
dependency generators that don't actually bother reading their input
and/or write anything back. This is almost certainly the ghost failure
we've occasionally seen in the test-suite too (rpm-software-management#2470).

Resurrect the explicit SIG_IGN that got removed apparently in commit
375a6b5. The matter was further
confused by NSPR (which we once relied on) always setting SIGPIPE
to SIG_IGN.

Suggested-by: Michael Schroeder <mls@suse.de>

Fixes: rpm-software-management#2949
pmatilai added a commit to pmatilai/rpm that referenced this issue Mar 11, 2024
If a dependency generator dies while we're still writing to its stdin,
it causes us to die rather randomly. Typically happens with fake
dependency generators that don't actually bother reading their input
and/or write anything back. This is almost certainly the ghost failure
we've occasionally seen in the test-suite too (rpm-software-management#2470).

Resurrect the explicit SIG_IGN that got removed apparently in commit
375a6b5. The matter was further
confused by NSPR (which we once relied on) always setting SIGPIPE
to SIG_IGN.

Suggested-by: Michael Schroeder <mls@suse.de>

Fixes: rpm-software-management#2949
pmatilai added a commit to pmatilai/rpm that referenced this issue Mar 13, 2024
If a dependency generator dies while we're still writing to its stdin,
it causes us to die rather randomly. Typically happens with fake
dependency generators that don't actually bother reading their input
and/or write anything back. This is almost certainly the ghost failure
we've occasionally seen in the test-suite too (rpm-software-management#2470).

Resurrect the explicit SIG_IGN that got removed apparently in commit
375a6b5, and restore SIG_DFL in the
child. The matter was further confused by NSPR (which we once relied on)
always setting SIGPIPE to SIG_IGN.

Suggested-by: Michael Schroeder <mls@suse.de>

Fixes: rpm-software-management#2949
ffesti pushed a commit that referenced this issue Mar 14, 2024
If a dependency generator dies while we're still writing to its stdin,
it causes us to die rather randomly. Typically happens with fake
dependency generators that don't actually bother reading their input
and/or write anything back. This is almost certainly the ghost failure
we've occasionally seen in the test-suite too (#2470).

Resurrect the explicit SIG_IGN that got removed apparently in commit
375a6b5, and restore SIG_DFL in the
child. The matter was further confused by NSPR (which we once relied on)
always setting SIGPIPE to SIG_IGN.

Suggested-by: Michael Schroeder <mls@suse.de>

Fixes: #2949
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

2 participants