/bin/time in time-1.9-11.fc33.x86_64 breaks timed make on GCC build: 1. Download GCC source. 2. Configure GCC 3. Build GCC with time $ /usr/bin/time make -j 12 all ... Command exited with non-zero status 2 20.27user 0.47system 0:08.49elapsed 244%CPU (0avgtext+0avgdata 185896maxresident)k 2448inputs+19944outputs (0major+237513minor)pagefaults 0swaps Downgrade to time-1.9-10.fc33.x86_64 fixed the problem.
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).