Bug 1898138

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).