Bug 744761 - Output of a --chroot command is fully buffered
Summary: Output of a --chroot command is fully buffered
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: mock
Version: el6
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Clark Williams
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-10-10 11:43 UTC by Davi Arnaut
Modified: 2011-12-13 19:57 UTC (History)
2 users (show)

Fixed In Version: mock-1.0.25-1.el5
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-12-10 19:52:40 UTC
Type: ---


Attachments (Terms of Use)
First attempt at unbuffering output of commands from --chroot (3.67 KB, patch)
2011-10-13 16:04 UTC, Clark Williams
no flags Details | Diff
Second attempt at unbuffering --chroot output (3.86 KB, patch)
2011-11-11 21:41 UTC, Clark Williams
no flags Details | Diff

Description Davi Arnaut 2011-10-10 11:43:25 UTC
Description of problem:

The problem is that the output of a non-interactive command is only printed to stdout after the command has been executed. This can be troublesome for cases where the command is executed within a CI system (where output indicates progress) and the command takes a long time to execute.

It would be nice if the output of the command could be spliced to the standard streams, perhaps in addition to the being sent to the log files. This could be a matter of passing stdout/stderr as some kind of logger to doChroot/logOutput, but without adorning the output.

Version-Release number of selected component (if applicable):

1.1.15

Expected results:

See the output of a --chroot command in real time.

Comment 1 Clark Williams 2011-10-12 22:14:58 UTC
The main routine for running things inside the chroot is in py/mockbuild/util.c and is named 'do'. It's used all over in mock so throwing a hack at it is almost guaranteed to break something. 

This will require a bit of thought due to the way we currently slurp up output from a command running in the chroot.

Comment 2 Davi Arnaut 2011-10-13 11:16:35 UTC
Agreed, there is even a bug in older Python versions where subprocess.Popen fails when passed stdio/stderr. I hacked around this issue by introducing a new spliceOutput parameter to 'do', which causes it to duplicate stdout/stderr and to wait() synchronously for the child to die.

Comment 3 Clark Williams 2011-10-13 16:04:49 UTC
Created attachment 528063 [details]
First attempt at unbuffering output of commands from --chroot

This patch modifies the routines involved in running a command inside the chroot, such that a 'printOutput' parameter may be passed into logOutput to tell the routine to print any output from the command immediately.

Comment 4 Clark Williams 2011-10-13 16:05:36 UTC
Davi,

I've attached my first cut at attempting to unbuffer --chroot output. Not sure I have it right yet but thought you might want to look at it.

Comment 5 Davi Arnaut 2011-10-14 13:22:54 UTC
Works for me.

Comment 6 Clark Williams 2011-10-14 13:48:16 UTC
That actually added tons of output for my regression tests which was unexpected. I need to go over it some more and figure out why I'm getting more output from my tests than I expected. I'm going to release 1.1.16 without this patch and then work a bit at figuring out what's going on.

Comment 7 Clark Williams 2011-11-11 21:41:48 UTC
Created attachment 533178 [details]
Second attempt at unbuffering --chroot output

I believe this one will do the trick and will not flood my test case log files with output.

Please review for next release

Comment 8 Davi Arnaut 2011-11-11 22:06:19 UTC
Looks good.

Comment 9 Fedora Update System 2011-11-27 23:53:50 UTC
mock-1.1.18-1.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/mock-1.1.18-1.el6

Comment 10 Fedora Update System 2011-11-27 23:54:38 UTC
mock-1.1.18-1.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/mock-1.1.18-1.fc15

Comment 11 Fedora Update System 2011-11-27 23:55:10 UTC
mock-1.0.25-1.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/mock-1.0.25-1.el5

Comment 12 Fedora Update System 2011-11-27 23:55:37 UTC
mock-1.1.18-1.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/mock-1.1.18-1.fc14

Comment 13 Fedora Update System 2011-11-27 23:56:04 UTC
mock-1.1.18-1.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/mock-1.1.18-1.fc16

Comment 14 Fedora Update System 2011-11-28 19:27:32 UTC
Package mock-1.0.25-1.el5:
* should fix your issue,
* was pushed to the Fedora EPEL 5 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=epel-testing mock-1.0.25-1.el5'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2011-5097/mock-1.0.25-1.el5
then log in and leave karma (feedback).

Comment 15 Fedora Update System 2011-12-10 19:52:40 UTC
mock-1.1.18-1.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 16 Fedora Update System 2011-12-10 19:57:12 UTC
mock-1.1.18-1.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 17 Fedora Update System 2011-12-10 20:06:18 UTC
mock-1.1.18-1.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 18 Fedora Update System 2011-12-13 19:56:39 UTC
mock-1.1.18-1.el6 has been pushed to the Fedora EPEL 6 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 19 Fedora Update System 2011-12-13 19:57:12 UTC
mock-1.0.25-1.el5 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.