Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1898138
Summary: | time-1.9-11.fc33.x86_64 is broken | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | H.J. Lu <hongjiu.lu> | ||||
Component: | time | Assignee: | Petr Pisar <ppisar> | ||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | urgent | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 33 | CC: | cra, kasal, law, leo, mst.misc, ppisar | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | x86_64 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | time-1.9-12.fc34 time-1.9-12.fc33 time-1.9-11.fc32 | Doc Type: | If docs needed, set a value | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2020-12-15 01:20:47 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
H.J. Lu
2020-11-16 13:57:38 UTC
It is caused by commit bbd427858e5c9ae5db5e9ca7ab5aff1558210869 Author: Petr Pí?sa?? <ppisar> Date: Wed Nov 11 14:15:37 2020 +0100 Do not leak a file descriptor of the --output argument to a command Do you have a smaller test? GCC is too large for any serious debugging. (In reply to Petr Pisar from comment #2) > Do you have a smaller test? GCC is too large for any serious debugging. You can use glibc build, which takes less than 2 minutes to build. It isn't a good idea to close stdout nor stderr in child. This patch works for me: diff --git a/src/time.c b/src/time.c index f998a53..a4738e5 100644 --- a/src/time.c +++ b/src/time.c @@ -738,7 +738,7 @@ run_command (cmd, resp) error (EXIT_CANCELED, errno, "cannot fork"); else if (pid == 0) { /* If child. */ - if (outfp != NULL) + if (outfp != NULL && outfp != stdout && outfp != stderr) fclose(outfp); /* Don't cast execvp arguments; that causes errors on some systems, versus merely warnings if the cast is left off. */ mbsync fails with SIGPIPE when it tries to call gpg2 to decrypt the IMAP password. This broke my email for 4 days until I just figured out it was /usr/bin/time causing the problem.
This fails:
/usr/bin/time mbsync -V account
This works:
mbsync -V account
The failure looks like this:
>/usr/bin/time mbsync -V account
Reading configuration file /home/cra/.mbsyncrc
C: 0/1 B: 0/0 M: +0/0 *0/0 #0/0 S: +0/0 *0/0 #0/0
Channel account
Opening master store account-remote...
Resolving imap.account.com... ok
Connecting to imap.account.com (w.x.y.z:993)...
Opening slave store account-local...
Connection is now encrypted
Logging in...
Authenticating with SASL mechanism PLAIN...
Command terminated by signal 13
0.14user 0.03system 0:00.59elapsed 29%CPU (0avgtext+0avgdata 8236maxresident)k
0inputs+0outputs (0major+1068minor)pagefaults 0swaps
mbsync is configured to get the IMAP password from gpg2 like this:
set smtp_pass=`gpg2 -q --for-your-eyes-only --no-tty --batch --logger-file=/dev/null -d creds.gpg`
Created attachment 1729778 [details]
A patch
I am testing this.
I see. The variable is initialized to stderr. I overlooked it. I will fix it. It's interesting that three other people gave +1 to the broken update. I'm sorry I provided the Mutt config, not the mbsync config, but it is basically the same: .mbsyncrc: IMAPAccount account Host imap.account.com User user PassCmd "gpg2 -q --for-your-eyes-only --no-tty -d creds.gpg" A simple reproducer: $ /usr/bin/time sh -c ':; ls -l /proc/$$/fd' total 0 lrwx------. 1 test test 64 Nov 16 17:26 0 -> /dev/pts/3 lrwx------. 1 test test 64 Nov 16 17:26 1 -> /dev/pts/3 0.00user 0.00system 0:00.00elapsed 85%CPU (0avgtext+0avgdata 3236maxresident)k 0inputs+0outputs (0major+334minor)pagefaults 0swaps (In reply to H.J. Lu from comment #3) > - if (outfp != NULL) > + if (outfp != NULL && outfp != stdout && outfp != stderr) > fclose(outfp); I think if (outfp != stderr) is enough. I will use the short version. FEDORA-2020-c797515bea has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-c797515bea FEDORA-2020-16861dc4cb has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-16861dc4cb FEDORA-2020-f6e5d12b45 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-f6e5d12b45 FEDORA-2020-16861dc4cb has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-16861dc4cb` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-16861dc4cb See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2020-f6e5d12b45 has been pushed to the Fedora 31 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-f6e5d12b45` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-f6e5d12b45 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2020-c797515bea has been pushed to the Fedora 33 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-c797515bea` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-c797515bea See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. argh, this cost me some hours to track down today, after an update of 600 packages... i habitually invoke make like this: /usr/bin/time ionice -c 3 nice make check LibreOffice builds fail in 4 level recursed makefiles in some bundled external library like this: make[4]: *** read jobs pipe: Bad file descriptor. Stop. the jobserver fds are allocated to 2,3 instead of 3,4 as before, and 2 is stderr... time-1.9-12.fc33.x86_64 from updates-testing seems to fix it, thanks. In my case this leads to a database corruption https://github.com/erthink/libmdbx/issues/144. And the https://bugzilla.redhat.com/show_bug.cgi?id=1898138 is duplicate of this bug. Another minor problem is the 'time' component at bugzilla.redhat.com mismatch to the `time` package. (In reply to Leonid Yuriev from comment #18) > Another minor problem is the 'time' component at bugzilla.redhat.com > mismatch to the `time` package. Leonid, I struggle to understand you. Could you explain me the mismatch? *** Bug 1904650 has been marked as a duplicate of this bug. *** (In reply to Petr Pisar from comment #19) > (In reply to Leonid Yuriev from comment #18) > > Another minor problem is the 'time' component at bugzilla.redhat.com > > mismatch to the `time` package. > > Leonid, I struggle to understand you. Could you explain me the mismatch? When submitting a bug, the component should be choices from the drop-down list. There is only one "time" entry in this drop-down list. For this entry the auto-fills field "Component Description" gets the string "A tool that performs date-based time calculations", which corresponds to some other utility and another package, but not to the /usr/bin/time. FEDORA-2020-c797515bea has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report. FEDORA-2020-16861dc4cb has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report. (In reply to Leonid Yuriev from comment #21) > (In reply to Petr Pisar from comment #19) > > (In reply to Leonid Yuriev from comment #18) > > > Another minor problem is the 'time' component at bugzilla.redhat.com > > > mismatch to the `time` package. > > > > Leonid, I struggle to understand you. Could you explain me the mismatch? > > When submitting a bug, the component should be choices from the drop-down > list. > There is only one "time" entry in this drop-down list. > For this entry the auto-fills field "Component Description" gets the string > "A tool that performs date-based time calculations", which corresponds to > some other utility and another package, but not to the /usr/bin/time. Thanks for the explanation. I reported the flaw against Bugzilla (bug #1907810). |